The central idea of this book is that we will create a set of questions on the teacher's "home page" which students can answer at their leisure, from their computer laboratories, or from their homes if they have network access. The questions, whose content is left to the teacher's (our) discretion, will be illustrated with a variety of question types (which may be cloned and altered). Every example included here is included to either teach an aspect of Perl, of HTML, or of Computer Assisted Testing.

Our design philosphy will be outlined here, since the difficulty level of what we are about to program does not correspond to our learning level. That means, for now, that we will avoid some parts of certain programs as we proceed, fleshing in details later once we are more sophisticated in our approach.

Logging into the system

We assume that every person signing onto our home page will be allowed to use our system, but guests and students will be treated differently. Thus, students will have their responses recorded, so that we can 1)see their incorrect answers, better to diagnose future help aspects of these questions, and 2)to keep a record of student's progress. Although we can not guarantee that a student's identity corresponds to that name which s/he logged in with, we can assert that student's who do "well" on WWW questions, and do poorly on the same kinds of questions on actual exams are either cheating (on the WWW) or are somehow subject to wierd psychological problems during in-class testing. Regardless, we recognize that unless some fraud proof identity scheme can be found, the examination problems offered on the WWW can never be used for un-monitored examinations!

Our Home Page

Since we will use some kind of sign in to our WWW questions, it makes sense to organize a home page as a typical HTML document, with whatever sensuous graphics you choose to use embedded therein, and have all other parts of the system .pl based, i.e. Perl programs, interpreted on the fly. This allows the home.html address to be published, and it should have one and only one link, to the sign-in Perl program. The Sign-In Perl Program should ask whether or not this current user is a guest or a student. For guests, we would like to know their names and addresses, since they are guests in our home. Of course, we can not compell them to give honest names, and the internet only supplies the address partially, so we may not be able to know that much about our guests, but that's in line with the internet philosophy that guests in our home can, if they choose, remain anonymous. Therefore, we will allow our guests access even if they refuse to sign in or sign in with a "false" name. In either case, we will assign them the name GUEST for purposes of logging their responses (vide infra).

For students, the situtation is a little different. Remember, we want to monitor their incorrect responses, to attempt to analyze what they are getting wrong. In fact, if they get an answer wrong, we want to offer them the opportunity to attach a note to their answer showing their reasoning processes, in case (very unlikely given how smart we are) that the question is wrong, and we should correct the Perl programming. Thus we want each student to have a .log file attached, which monitors what is going on, i.e., keeps us informed both about what the student is doing, and what answers the student is inputting.

From our point of view right now, that means that we need to pass a token to each Perl program pointing to the student's identity, e.g., the student's name. This means that in the sign on Perl program, we need to create this token, and pass it to each called program as the student clicks from page to page (from the student's point of view). Further, we need to guarantee that the next time the student logs in, the token is the same. To do this, we will only have the student give his first and last name once, the very first time s/he uses the system, and we will create a class role book of registered students. When the student comes in a second time, the class role will appear and the student will choose his/her name from the list (and we will create the exact same token as the one we created the first time the student used the system). If the student chooses to log in with another name, fine. S/he will be loosing credit for achievement, but causing no harm, so who cares.

Since we start as relatively unsophisticated programmers, we will show where in our sign-in program this token is to be created, but we will defer actually writing that sign-in code until we are more advanced in our skills.

Finally, we will attempt minimal security arrangements, to prevent students from altering other student's records (oh what a world we live in). To do this, we will issue a password to each student which will be the password for the next session. The student will need to write down the next_password each time s/he uses the system, so that if it has changed, the student knows that someone has infiltrated his/her "space". Since our log files will contain date and time information, i.e., time-stamps, we will be able to look at the student's records (.log files) and ascertain at least when this chicanery took place. From our (the programmer's) point of view, this means that we will have to dynamically update a password file, one which is kept out of view and inaccessible to the casual internet browser, but which we can read and write at will. We also need to write a password generator, which will generate random passwords from printable characters. We will need to decide if we are using only letters, only numbers, or both, and whether the letters should be upper case, lower case, mixed, etc.. In other words, we will need to translate the grandiose words (above) into reality, paying strict attention to each and every detail.

Further, this means that students can come onto the system the first time without a password, and we will then generate a password for session 2. When the student comes for session 2, a password for session 3 will be generated, etc., etc., etc.. Careful students will quickly learn to record their passwords as soon as they are generated. Others will have to come to their teachers (us) to have their passwords reset (which means we will have to write a password reset program!

Our Main Menu

Once students have logged into the system, i.e., supplied their passwords, the system will open up a menu of topics on which test questions may be taken. Organizing the material into topics is quite reasonable, so that in future years, the order of presentation can be altered easily. For most of us these topics do not change drastically from year to year, and usually, we add one or two, dropping others as we proceed down life's little highway. Since the old questions may someday be useful again, we usually will not erase them, but instead relegate them to an inactive status. Our students won't mind, but the more adventurous of them might venture into these "inactive" areas to see what they are missing. Who knows.

Each topic menu will retrieve the current student's name (token) to pass it on to each question as it is called (chosen by the student). In this way, we know that name (token) for the current user, and can establish a file "name.log" to record the student's activities. Further, we will equip each question with a mailer, so that students can write directly to us if they have problems. Although we will not be online with them, we will be able to respond either electronically, or in the class room itself. It is important to offer the student the opportunity to criticize the question directly, since if the student gets it wrong, and is convinced that s/he has the right method, and if the help we offer is inadequate, then there is something really wrong, and we should always be aware that the student may indeed be right, and that WE MIGHT BE WRONG!

Again, as with the original sign in, we will defer some of these data logging and mailing problems until a latter time, so that we can concentrate on the dual goal of learning Perl and writing questions.