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!
Make sure that there isn't a lot of old, discarded code that you no longer use.
Take a look at any warnings signalled by IDEA. If you choose to ignore a warning, make sure you do so because you know the warning is wrong, not because you don't want to spend the time to change your system.
Clean up the formatting of the interfaces, classes and JSP documents you have created. IDEA has automatic code formatting and layout for Java code.
Check your naming conventions. Make sure you use the Java standard naming convention, and even more importantly, make sure the names themselves make sense and are easy to understand. Renaming classes, methods, fields or parameters is easy in a modern IDE! In IDEA, just place the cursor at the identifier and press Shift-F6.
Make sure implementation details aren't too widely visible. Maybe some fields ought to be private rather than public (Encapsulate Fields in IDEA).
Check your class, method and JSP structure. Maybe you really ought to introduce a couple of separate classes handling certain things instead of cramming too many things into a single class. If a method is too large, and it consists of several subparts where it would make sense to make those subparts into separate methods, then do so! In IDEA, mark the part that should be placed in a new method and select. Similarly, if some things are repeated in many JSP pages, you might want to extract an include file.
Make sure that errors are handled correctly everywhere.
For example, if a servlet cannot connect the JDBC database, it should fail gracefully and tell the user what is wrong. Try it! Terminate MySQL in the middle of a session and see what happens.
Catch errors where you know what to do with them.
Try logging in and then shutting down the database at various times. What happens?
Try logging in with a short session timeout configured in web.xml. Start writing a message but wait long enough for the session to time out. What happens when you submit? Is the message lost?
Make sure that your code is readable.
This includes being reasonably well commented — we don't require that you comment code when it is intuitively obvious what it does or should do, but it's nice to have some kind of clue when it comes to more complicated functions.
The code should also be indented correctly (feel free to use your own indentation style, but we don't want to see code where indentations are misleading. You can use IDEA or Emacs to automatically indent your files, or tools like JIndent.
In IDEA, you can lay out your code according to the settings you have defined in IDE Options using
In addition to reviewing your code, you should naturally also review your design and test the usability of your finished project.
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 firstname.lastname@example.org:
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).
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.
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.
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.
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.
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