Part 6: The Finishing Touches

You have now implemented the user account database and the message forum, and you have added a number of extensions to the basic project. It is time for the finishing touch -- in other words, it is once again time for a feature freeze where you focus on polishing the system and making it easy to use, as well as cleaning up your code base.

Like the checkpoint after the first part of the message forum, this is not an exercise you should skip simply because the goals are somewhat more vague than for the other exercises. Usability and code quality are very important, and may affect your final grade! This exercise should take at least several hours, possibly much more.

As a first step, take a look at the application yourselves. Imagine that someone else has written this message forum, and that you want to use it on your own web site (or you are a casual user visiting a web page where the forum is used). Is there anything you would complain about? Anything you think could be done in a better way? Are error messages difficult to understand? Is the application difficult to use? Are some parts of the application "disconnected" from other parts, making it difficult to navigate between different functions? Is it ugly? If so, take some time to polish the design and the user interface.

Then, take a look at your code. Check your error handling, fix your comments, ensure that you don't have a lot of old obsolete code lurking in your .java files, and in general clean up the classes and interfaces you use. You should be proud of the quality of the code you have written!

You should also feel free to ask the lab assistants for advice during scheduled lab hours, before the final demonstration! We'd be happy to take a look at your system and perhaps suggest a few improvements.

The following are some points you might want to consider when you review your design and your code. This list is not exhaustive. There are many other important points that may not be listed here!

In addition to reviewing your code, you should naturally also review your design and test the usability of your finished project.

The end!

After spending some hours (or maybe a day) on the previous exercise, it might be time to hand in your lab. Please make sure that you follow these instructions!

You must hand in a signed "lab wrapper" (labbomslag) with all relevant information filled in -- but you should not print out your code. Instead, you should hand in your code electronically, together with some other information specified below, in a single e-mail to

  1. A zip or tar.gz archive containing your entire project directory or directories. This archive must include all Java source files, all JSP and HTML documents, and all other information related to your project.

    The archive must include the IDEA .ipr and .iml files that define your project. It must be possible to open the project on our computers. You should verify this by unpacking the archive in a temporary directory under /tmp, opening the project from this location in IDEA, and verifying that you can compile and run your project without warnings or errors.

    As stated in the lab instructions, all information should be under a single project directory, and should be copied from that directory to the Resin deployment directory ~/resin/doc/tddi48 when you "make" your project. You should not have created files (such as HTML documents) directly in the deployment directory. If you have, then you should reconfigure your project to include those files in the project directory instead (ask Jonas if you're not sure how to do this).

  2. A number of screenshots of your system, preferably in PNG format. This helps us remember which project was yours when he is reading your code, and also helps us understand your markup and tags in JSP or HTML documents.

  3. A list of all extensions you have implemented. This is important. Having to search your code to determine which of all 15-20 extensions are implemented takes much more time than simply verifying that the extensions on your list are implemented, so if you have not included such a list, your project will be placed in the "pending" pile of projects and will not be graded until the next time we have some spare time.

  4. Any design documentation or user documentation you may have written for your forum system.

Please note that the directory structure you hand in should be well organized and easy to understand, and it should not contain obsolete (unused) files or compiled .class files! Everything relevant should be handed in, and everything which is handed in should be relevant. If the structure is a mess we may ask you to clean it up and hand it in again.

Creating Screenshots

You can create screenshots using tools such as xv or gimp. You don't have to print them -- just attach them to the email when you send the project file.

Creating Archives

Hopefully all the information you need to send is already placed within a single directory. If this is the case, then all you have to do is:

    cd directory-containing-project-directory
    zip -r noone123.notzip myProjectDirectory

(Why are we calling the archive "notzip"? Because the e-mail system does not accept zip attachments. Send it as "notzip" instead. We'll rename it to "zip" when we've received it.)

Then check the contents of the archive and make sure all relevant files are included:

    unzip -v noone123.notzip | more

Jonas Kvarnström
Senast ändrad: 2006-02-16 23:42