This handout contains several unrelated sections, covering various things that we need to do as we pick up the course after Spring break.
Here is the plan for the rest of the course: Homework 8 is due this week, amd you will have to complete your research report for Homework 5 before the end of the term. There will be one more regular homework assignment, on the topic of databases. There will be a test next week, on Wednesday, April 1. After that, we will cover various topics in J2EE server-side programming, but the main work of the course will be on the final project. Over the last four weeks of the semester, several classes will be devoted to organizing, planning, and working on the project.
The next topic in the course is databases. We will cover the MySQL database and how to use it from the command line. More importantly, you'll learn how to use MySQL with Java web applications. The reading for this material is Chapters 13 and 14 of Murach.
A database is just a collection of data stored on disk and organized in a way that makes it possible to do certain operations efficiently. In a relational database, data is organized into tables made up of rows and columns. Each column in a table has a name and a data type, and every row has an entry for each column. Furthermore, columns can be indexed. An index is an auxiliary data structure that makes it very efficient to find the rows that have a given value or range of values in a given column. A RDBMS (Relational DataBase Management System) is a server that manages a collection of relational databases. (To confuse things, sometimes an RDBMS server is itself referred to -- incorectly -- as a "database.") An RDBMS makes it possible to create and destroy databases and to perform various operations on the databases that it manages, and it provides a security system that determines which users are allowed to perform which operations. MySQL is a widely-used RDBMS; it is an open-source program that can be used without charge. It is especially popular for use with web applications.
For the purposes of this course, you have a MySQL database under the MySQL RDBMS running on mathb.hws.edu. The username for accessing the database and the name of the database are both the same as your regular Linux user name (with a format like zz9999). You will need a password to access the database. The password is a randomly chosen word that is different for each user. Here (on the hard-copy handout) is your password:
The password for user ___________________ is _________________________.
To access this database using the console (command-line) interface, use a command such as the following on any Linux computer on campus:
mysql -u zz9999 -h mathb.hws.edu -p
Of course, you should replace "zz9999" with your own user name. You will be asked for your password. Once you are connected, the prompt will be changed to "mysql>". You can type commands to mysql at this prompt. The first command that you should give tells mysql to use your database. This command has the form:
use zz9999;
where, as always, you should replace "zz9999" with your own user name. Any commands that you give after this will work with this database.
One very useful command has the form "source <filename>", where <filename> is the name of a file that contains database commands. This tells mysql to read the file and execute the commands in it. For example, if you type the following lines into a file named tabledef:
drop table if exists users;
create table pollusers (
id int PRIMARY KEY AUTO_INCREMENT,
user varchar(32) NOT NULL,
password varchar(32) NOT NULL,
unique index(user)
);
insert into pollusers (user, password) values ("fred","password1");
insert into pollusers (user, password) values ("jane","password2");
and then use the command source tabledef at the mysql> prompt, your database will contain a table named pollusers with columns named id, user, and password. The last two lines of the file add two rows to the table. The first line deletes any existing table named "pollusers" before creating the new one. A file like this one can be useful during development, when you want to recreate your database tables with a known initial state. I also advise you to use the source command whenever creating tables, since it can take a large number of tries to get it right and because it can be useful to save the files that you use to create the tables.
You will find more information about the mysql console in Murach (although for some reason he doesn't mention the source command).
Homework 8 (from Lab 4 and Lab 5) is due this week. I will need a copy of your completed "polls" project. Since this is a server-side project, you can't post it on math.hws.edu. Instead, you should follow the following procedure for turning in the project:
The ".war" file that you copied in the last step is a "Web ARchive" file. It contains all the files that are needed to run your application on a server, including configuration files, compiled java files, and content files such as JSP, HTML, CSS, javascript, and image files used by your appliction. A web application can be deployed in a J2EE server simply by adding the war file to the server. (For Tomcat, this can be as simple as copying the war file into Tomcat's webapps directory.) I will deploy your application to the Tomcat server running on port 8080 on mathb.hws.edu for testing.
For the final project in this course, you will work in a six-person group to create a fully functional web application -- hopefully one that is useful. One possibility is to create a user site for alumni of the Department of Mathematics and Computer Science, or possibly a complete department web site. I am certainly open to other possibilities; we will discuss ideas in class.
There is a variety of tasks that need to get done during the planning and development of a large web application, including:
Some of these tasks should be done by the entire group (#1), or at least most of the group (#4). Some will require contributions from all or most of the group, but not necessarily working together (#5). For some, one or two people can take primary responsibility (#2, #3, #7, #8). To make sure that work on the project proceeds steadily, we will follow this schedule as closely as possible:
The largest part of the grade for the final project will likely be based on the work of the group as a whole. However, there will also be a significant part of the grade that is based on individual performance. In the case of an incomplete or failed project, the individual grade will be especially important. For this reason, all files in the project should include a comment at the top with the names of the people who actually worked on that file and some indication of the nature of their contribution (e.g. "wrote most of the code", "added method XXX", "did some minor code polishing", "fixed bug in method XXX"). Reports that are turned in as hard copy should also include the names of the people who prepared them. I expect that everyone in the group will have some files and reports for which they bear primary responsibility. At the end of the project, everyone will turn in an individual summary report of their work, including a self-evaluation and an evaluation of their team. I strongly suggest that you keep a log of the work that you do on the project, and turn in that log as part of your final report.
When several people are working on a programming project -- as you will be for the final project in this course -- it's useful to use a version control system such as CVS or SVN to hold the official copy of the project and to keep track of changes. NetBeans has support for both of these. I am more familiar with CVS, so we will use that.
I have created repositories for use for the final projects in this course. There is one repository for each group, in the directories /classes/s09/cs271/cvs/ateam, /classes/s09/cs271/cvs/bteam, and /classes/s09/cs271/cvs/cteam. You will have permission to access the repository for your group (and so will I).
There are four main basic CVS operations: Import a project from NetBeans into CVS; Checkout a project from CVS into NetBeans; Update the NetBeans project to apply changes that have been made by other people to your copy of the project; and Commit changes that you have made in your copy to the copy in CVS.
For the final project, one person will have to initially create the project in NetBeans, and then import that project into CVS. This will only be done once! To do this: Right-click the project name in the "Projects" pane. In the pop-up menu, go to the "Versioning" submenu and then select the "Import into CVS Repository" command. In the dialog box, type in the "CVS Root" as something like this (but with your own user name instead of "zz9999" and with "bteam" or "cteam" instead of "ateam" if appropriate):
:ext:zz999@math.hws.edu:/classes/s09/cs271/cvs/ateam
As you type this, a radio button labeled "Use External SSH" will appear, with a box for your password. Leave the radio button selected, and enter your Linux password. (You can check the "Remember Password" box or not, as you prefer.) Click "Next." Type in an "Import Message" such as "Initial import of final project." No need to change any of the other settings. Click "Finish". If nothing goes wrong, the project will be in the CVS repository, and NetBeans will remember that the project is under CVS control (so that it knows where to go to "Commit" and "Update" the project).
Next, the other five people in the group must checkout the project from CVS. Each of them will only do this once! To do this, use the "Versioning" menu in the main menu bar; go to the CVS submenu, and select the "Checkout" command. In the dialog box, enter the information for the CVS Root and password, just as described above for the import command. Click next. Enter the project name in the "Module Name" box, or hit the "Browse" button next to the box and select the name in the popup. Click "Finish." You should get a message asking you whether you want to open the project. Say yes. The project should appear in your "Projects" pane, and it should be associated with CVS.
Note that when you right-click a project that is under CVS control, the popup menu will contain a "CVS" submenu that has a bunch of new commands relevant to working with CVS. Among these are the Commit and Update commands that you will use regularly while working on the project. Remember to use "Update" to get the changes that other people have made to the CVS copy of the project. Use "Commit" to send the changes that you have made to the CVS repository.
Note that when you have changes to commit, best practice is to first Update, before doing Commit. This is to avoid having conflicting changes in the repository. Conflicting changes happen if two people edit the same region of the same file and they both try to commit those changes. The changes will have to be "merged" before the second commit can succeed -- and that's something that you want to try to avoid. If you've divided up responsibility for working on different parts of the project, it shouldn't happen.