The Final Homeworks

1. Due Monday 4/30 by 1:00 pm. Final electronic submission of project. This will be the graded version of the project. We will make a copy of the archives just after 1pm. (It's okay if want to continue to work on the project after that - for instance, to give a better demo during your presentation - but the 1pm Monday version will be the version we evaluate.)

2. Due Monday 4/30 in class. Scribe report #3 (from group member who hasn't yet done one.)

3. Due Monday 4/30 in class. From each team member we need hardcopy of a short write-up (README) about your part of the project.

   For most people this should be half-page to one page. We're not looking for long multi-paged detailed software documentation (who reads the giant books/docs that come with software?).

   This document is your opportunity to give us important info about what you did and how your progra works. When grading, we're faced with looking at many source code files, and running/ evaluating a program that might be quite different from that of other people. Tell us, succinctly, things as:

   • how to run it

   • features it provides and how to use them, especially ones that are especially intereesting or for which it's possible we might not encounter/notice them (maybe you have actions bound to keys - how will we know that unless you tell us - we're not gonna go hunting for all possiblities in code.)

   • backend people should probably give some kind of list of the main functions/operations they provide

   • anyone who developed testing routines/data should tell us about that (since we might not notice it in your submission otherwise, and it can be a important piece of what you've done)

   • if there's a lot of "junk" in your submission, make sure to tell us what's good / what's junk ("ignore files x, y, z; that was my orig. stuff and is not used much now")

   • if there are features that aren't complete/done function fully correctly, but for which you think you've done a bunch of good work, tell us, so we can look at the relevant implementation. (That's not the same as features you put stubs in for but never really go to making any effort on - those aren't likely to be worth much.)

4. Presentations:

   • Monday 4/30, in class: Teams 1, 2, 3 project presentation

   • Wednesday 5/2, in class: Teams 4, 5, 6 project presentation

   • Friday 5/4, in class: Teams 7, 8 project presentation

   Class attendence is expected each of these three days, regardless of whether you're presenting or not.

   You'll have 15 minutes. This will be strictly enforced.

   The presentation will not be a *major* part of your grade. Your project will be evaluation by your code submission. The presentation is an opportunity for your team to tell the class about it.

   It will be a little challenging to do a good job in 15 minutes.

   I suggest this format:

   • (5 minutes) "What it was like" Something (you choose the focus) about your team's experience of doing the project - what your initial plan/design/goals were, how you interacted (email, phone, in-person, on-line chatting, ...), how your finished product(s) compare to initial goals, special challenges and/or successes, ...

   • (5 minutes) "How it works" Pick one very specific tiny feature/piece of your implementation (of just one part - not each component - there's no time for that) and tell us about it. You do not have time to show pages and pages of code and discuss overall program structure.

     Tell us, perhaps, about how you implemented your favorite special feature ("here's how we made the cool sound effect when pages turn") or something about a special challenge that arose during implementation and how you resolved it.

   • (5 minutes) "Here it is" Demo. You can *try* to demo both the composer and player, but if you plan to do this, do a dry run yourselves before class - can you really do a composer and player demo in 2.5 minutes each?

   Whether 1, 2, or 3 people do the actual talking/presenting is up to you; whatever the case, it'll viewed as a presentation by the whole team.

Homeworks 10 & 11, due Friday 20th April and Monday 23rd April.. Homework 10 is a scribe report; Homework 11 is completion of Phase 2 of the project. The pdf file projPhase2 has details about the assignment.

Homework 9 due Friday 13th April. The homework, for each team, is to have working Phase 1 Composer and Player applications, and backend (Role 3) software checked in to the team's CVS repository. We'll take a "snapshot" of the CVS repository after class and then evalate each team's software in this frozen snapshot copy of the work. Here's a sample of what Phase 1 composer and player applets might have (save/load functions are disabled in the web-browser versions of these): demoalbum applet. Then, Friday afternoon following class, we will put the code for the demo applet into the TeamSandBox repository: this will enable all students to see working versions of composer, player, and backend java source code. (The thinking behind this is that, going forward to Phase 2, you will at least be able to build on something that works, even if you weren't able to get that far yourselves by Friday.)

Also, remember that team meetings with Profs Cremer and Herman will be available on Thursday, in the same time slots as the last such meetings.

About images and applets in Java: I wrote a small demonstration applet called demoImageLib and put that in the TeamSandBox CVS repository (which you can check out using eclipse). The demo uses the Swing version of applet (JApplet); I spent some time before writing the program using a search engine looking for things like "japplet examples" and "java swing tutorial" and "japplet swing examples", paying attention to the first few search results and especially pages from Sun. The demo illustrates reading images from a zip file; when you check out demoImageLib you will get a file called imagelib.zip that contains many images, and the applet uses methods of java.util.zip to read entries of the zip file. This demo is useful as another example of writing an applet, showing techniques like the MouseAdapter and JSplitPane, that I discussed in class. One value of the demo is for Role 1, the team members writing the Composer -- you can use the code in this demo to select pictures to put into the album. Another value of the demo is for Role 2, because the images themselves (which could be large jpg files) should not be serialized and stored in the album; rather, the album should contain the image names, and then the Player can fetch the actual images from the zip file, using the technique of demoImageLib.

Project Phases (28 March): here (pdf); now contains homework assignment due 6 April.

Project description (20 March): here (pdf); now contains homework assignment due 28 March.

About serialization in Java: I prepared a small demonstration called demoSerialize and put that in the TeamSandBox CVS repository (which you can check out using eclipse). To prepare this demo, I read the textbook, one other Java manual, and found this link to be a helpful introduction.

How-to mini-lectures (using Flash) on Eclipse and CVS.

• How to create a project (and add to CVS repository, using Eclipse). Note: this presentation has a bug (I forgot to save a change to my HelloWorld program, but that turns out to be a nice bug to correct later).

• How to change a project (again, using CVS and Eclipse). Note: this fixes the bud in the previous version and commits the change.

• Creating a Jar -- this is a more advanced topic, how to create a package, turn it into a Jar, modify the Jar. Some of the techniques here could be useful for other things.

• Using a Jar -- illustrates how to use the Jar file from the previous step, plus checking in Jar files to CVS. This step also illustrates the technique whereby students could check in arbitrary binary and text files, so UML, state charts, etc, can be part of the project shared by a team.