Assignment Log Project

[Marilyn de Queiroz]

Just to get this new thread started.

Originally posted by Daniel Olson:
I am more familiar with databases too, and it may be the best way to do this project. However, I recently have started doing applications combining Java with XML and have been impressed with some of the things that combination enables a developer to do. Now everything I do I think, "Can I use XML for that?" When you have a hammer, everything looks like a nail.
For the class log project, XML seems to make sense to me because the amount of data that we would need to manipulate is small and a database seems overkill unless you already have a database setup and ready to plug into. Using XML would be very portable--no tables to set up and might only require three or four small files that could be put somewhere in the servlet folder.
I would be interested in helping with the project. Maybe we could do two versions (database and XML) and then discuss what features we like and don't like about each version.
I have been rewriting my examples so that they fit the Class Log project better. I should have time this weekend to finish and will send the examples. So far Johannes, Bill, and Marilyn are interested in seeing the examples.

and Peter.

Originally posted by bill bozeman:
Let's first hammer down what data we want and then go from there. The data may just be what Johannes put in his table, but there may be some other ideas we want to throw around.
Bill

[This message has been edited by Marilyn deQueiroz (edited March 24, 2001).]

[Johannes de Jong]

Fields I'd like to see in the Assignment Log:

• Number Position in Assignment Log
  
• User-id Same one used at the Java Ranch
  
• Assignment Java-1a, Java-1b Java-2a etc.
  
• AttemptNumber system keeps track of it
  
• Class name Hundred,EvenOrOdd etc.
  
• Activity DateTimestamp Date last activity took place
  
• Status new-student,submitted attempt, being nitpicked,nitpicked
  
• Nitpicker User-id at the Java Ranch
  
• Day counter Days since last status change
  
• Students e-mail address NOT SHOWN !!!
  

To have the log fit on a 800 x 600 screen I see us use bitmaps for the Nitpicker & Status fields I also think that using bitmaps will "visualige" the whole process. I've got some ideas for the activity and as soon ad I have time I will draw them post them here.
My "design" is based on the following assumptions :



• Student submits his assignment via the JavaRanch site
  
• Extra work from the nitpicker, ie changing the status
  


I'll explain my design using "transaction" flow
1. A new student registers. This he does by pressing the <register> button on he Assignment Log page. The same screen(type) we get now when we post a new topic or reply to a topic asking us for our user-id and password will appear. The normal type validation will be done by the system ie. not registered before etc.
The default values of the fields will be set and the new student will be shown on the activity Log when refreshed.
2.The student submits an assignment attempt. Press <submit> button on the Assignment Log page Again the verification screen will appear. The student will enter the values and will now
see a standard Open File screen. He selects the Java file he wants to submit and <OK>. The system than takes the file and sends it to the Java Server.
The system off course check if the student can submit a new assignment before even allowing him to get to the Open File screen.
The appropriate fields for the student gets changed and the system waits for the nitpicker to "pick" up the assignment
This can be done I saw a young boffin at my work do something similar on Friday. I'll corner him and pick his brain next week.
Why this way ie. submit via the Java Range for one a standard text file is sent no more posting about HTML e-mail, tabbing etc. Also automatic registration of a new attempt.
3.The nitpicker picks up the assignment. The Nitpicker selects the assignment/ student he wants to nitpick and the system e-mails the attempt to the Nitpicker.
Off course the <verification screen> is used to validate that it is a nitpicker picking it up.
At the moment the "whole" assignment gets nitpicked by one nitpicker. I personally think we should keep it this way. The system will thus check if it is the right nitpicker that is picking the attempt up.
But why this action , why not let the system send a e-mail to [e-mail] and work the same as before. By doing it "my way" the student gets "told" that the nitpicker has started looking at it.
4.The nitpicker is finished nitpicking and sends the nitpicked attempt with comments back.
The system will use the students e-mail address that is kept in the database here for that. Why I'll use an example. I've started using my e-mail address at work since last week. I submitted an attempt on Friday and the nitpicker did not respond before I had to leave for home to start my weekend. I did not want to wait till monday to see my nitpick so I sent Marilyn an e-mail to ask her to mail my nitpick to my home e-mail address. Extra work for Marilyn. This way the system will take care of it. Off course the student must be able to change his e-mail address. update: well the Nitpick came to work, lost a whole weekend , the use of this functionality has proven itself to me
If the student passes the system will automatically send the standard solution to the student.
Basically what I'm proposing is a Work-flow" system. How we can/ will technically implement it, I cant say, I just don't have the necessary expertise for that .
I'm posting this to get the discussion going.
Forgive me my long posting and the mistakes in this document.

[This message has been edited by Johannes de Jong (edited March 25, 2001).]

[Daniel Olson]

Johannes,
You have put a lot of thought into the Assignment Log project. I like you ideas, but it sounds like a pretty big project. I suggest we do a smaller project while we are thinking about and working on the bigger project. The smaller project would be to do a simpler Assignment Log similar to the table that you have made, except that each person could edit his or her own information using servlet based web pages. The smaller project not be in place of the more full-featured solution you are suggesting, but could be done at the same time as or after the smaller, quicker project. After the smaller project is done, you will have more time to work on the bigger project, since you will not have to spend so much time updating the log.

[Johannes de Jong]

Daniel
Yes I agree the small project should be implemented a.s.a.p. it cost me nearly an hour to update the log this morning.
I do think that someone should take the role of "project leader" and start handing out tasks so we can get started. I don't have the required knowledge to assume that role. Bill would be the logical choice as he initiated the project. But I leave that in the open. However lets set a target date of say the 27th to finalize who is going to run with this as project leader. It will be that persons responsibility then to get "staffed".

[bill bozeman]

Johannes, I like your ideas, but I think we all seem to agree let's wait and do this is phases.
For Phase 1, all we really need is to create the log and have a way to update it. I say for right now, an admin person does that and not even the student yet. Once we know it all works well, then we can talk about letting the students change it directly.
First I think we need to nail down the data and what it will do. As I have said, I think all we want is a table that shows all the current students and where they are at in the proccess. We do want to record when they advanced from one assignment to the next, how many times attempted, and date of last submission.
So here is the data that I am think:
1. First Name
2. Last Name
3. Current Assignment
4. Date of first submission (for current assignment)
5. Date of final submission (for current assignment)
6. Date of last submission
7. Number of attempts
Other possible things:
8. Date nitpicker sent last response - This may be too much for the nitpickers, but if we knew the last time they submitted something, and the last time the nitpickers replied, then we know who is waiting on who and how long it usually takes to send in an assignment and how long it takes to get a response.
9. Name of nitpicker - I don't know how I feel about this one, but I will throw it out there. We have a few nitpickers now, so it may be worthwhile knowing who is doing the nitpickings for who. This isn't something I would display on the log, but could help see trends in the different nitpickers. If I am nitpicking someone on Java 1a and it takes the average user 5 tries to get by but it takes students who have Marilyn 2 tries to get by, then maybe I am looking at somethings to hard and we need to review that. Really an internal thing, but something to discuss.
10. Students email address. This is required as part of posting messages to the forums, so I don't know if it is needed here. But maybe. I don't want to have too little or too much data, so this is one we may not need.
Anything else anyone can think of?
Bill

[bill bozeman]

With the above in mind, in database terms, I see this as 3 to 4 tables. Here they are:
Students

• studentID
  
• firstName
  
• lastName
  
• email ???
  
• dateRegistered (timestamp of when the student first goes on the log)
  
• activeFlag (in case student quits)
  

Assignment



• assignmentID
  
• name
  
• description (a one line brief description)
  
• order (just in case we want to move assignments around)
  
• activeFlage (in case we want to take some down)
  

Nitpickers (This table may not be needed)



• nitpickerID
  
• firstName
  
• lastName
  
• email
  
• activeFlag
  
• dateStarted
  

StudentLog - Main table that pulls everything together



• studentID
  
• assignmentID
  
• nitpickerID ???
  
• dateStarted
  
• lastSubmissionDate
  
• lastReceiptDate
  
• dateFinished
  
• attempts
  

What do ya'll think about the above? We'll adjust with additions or changes of required data. Haven't started to think about XML version yet. Anyone want to throw up an example of a tag structure for XML?
Bill
[This message has been edited by bill bozeman (edited March 26, 2001).]

[Johannes de Jong]

Daniel & Bill, I will comment here tommorow, sorry time zones

[Marilyn de Queiroz]

Originally posted by bill bozeman:
So here is the data that I am think:
1. First Name
2. Last Name
3. Current Assignment
4. Date of first submission (for current assignment)
5. Date of final submission (for current assignment)
6. Date of last submission
7. Number of attempts

Other possible things:
8. Date nitpicker sent last response
9. Name of nitpicker
10. Student's email address.

What is the difference between #5 and #6?

I think some of these items would be good for stats, but I'm not so sure about making everything public. It certainly would decrease flexibility.

[Daniel Olson]

Bill,
I like you idea of doing the project in phases. However, what you have described should maybe be phase 2 instead of phase 1. We have an immediate need to replace what Johannes is doing with something that students can edit directly so that he does not have to take so much time doing the grunt work of changing the table everyday.
I propose that for phase 1 all we try to do is to replace Johannes' table so that it is more easily editable and not add any complexity. Keep it as simple as possible.
The tables you have defined make sense, but won't we need at least two displays--one like Johannes' table and another showing statistics of all the assignments.

[Daniel Olson]

Are we planning on doing this as servlets? Is Java Ranch going to allow us to put some servlets on the site?
Bill, are you willing to be the project leader? I agree with Johannes that you are the logical choice.

[Daniel Olson]

Sorry three posts in a row.
The XML files I emailed is one way to do an XML version. Here is an example with two records:

?xml version="1.0" encoding="UTF-8"?
doc
  item studentName="Barney Fife" assignment="Java-1a" assignmentName="Hundred" attempts="18" datePosted="March 13, 2001" /
  item studentName="Mary Martin" assignment="Java-1a" assignmentName="Hundred" attempts="2" datePosted="March 13, 2001" /
/doc

(I had to take the angle brackets out so that the code would show.)
The fields "assignment" and "assignment name" could be combined.

[This message has been edited by Daniel Olson (edited March 26, 2001).]

[Marilyn de Queiroz]

I agree with Bill "For Phase 1, all we really need is to create the log and have a way to update it" and Daniel "replace Johannes' table so that it is more easily editable and not add
any complexity."

The simpler the better. We can add complexity later.

In my opinion, all we really need to start with is a table with the student's name, which assignment he is on and which attempt of that assignment, and the date he submitted that attempt (so we know he is still current) AND a way for each student to edit his own status.

Later we can add sorting (alphabetical by user name or date submitted or date the user started the cattle drive or assignment number, etc)

Later a new student will be able to add himself to the log (Registration at JavaRanch would be verified in the process).

After that we can add statistical analysis.

Then, perhaps, we will tackle automation of the submission of the assignments (although I'm not convinced that is a totally good idea). This part could easily get really complex.

[bill bozeman]

What is the difference between #5 and #6?

The only difference here is #5 shows when they were allowed to pass and #6 would show last time they submitted something for that assignment. A better description for #5 would have been Date Completed.

I think some of these items would be good for stats, but I'm not so sure about making everything public. It certainly would decrease flexibility.

I agree. I was thinking in terms of overall data not just the data we display, so as Danial put it, statistical data. I would only display the same things Johannes is displaying now.

I like you idea of doing the project in phases. However, what you have described should maybe be phase 2 instead of phase 1. We have an immediate need to replace what Johannes is doing with something that students can edit directly so that he does not have to take so much time doing the grunt work of changing the table everyday.

True. I think we need to get the table working, port over all the current data, and then test it for a little while before making it public, but you are right, we should think of it in terms of phase 1.

Are we planning on doing this as servlets? Is Java Ranch going to allow us to put some servlets on the site?

If we get a good version of this, I am pretty sure Paul will allow us to post it. So yes, I was thinking of a servlet. I brought this up with Marilyn, Paul, and the other moderators before I contacted Johannes and you. I wanted to make sure we had the go ahead before we pursued this.

Bill, are you willing to be the project leader? I agree with Johannes that you are the logical choice.

I would be happy to take the lead on this.
Bill

[bill bozeman]

Ok, to make things simpler, let's drop the whole nitpickers table. I wasn't really sure if we needed this anyways. I brought it up now just in case we did want it because if we add it in the future we have a lot of records with either null values or we have a lot of old record we will have to go back and update. But as that is really not a need, let's get rid of it.
The other 3 tables are pretty basic though. Table that holds basic contact info, table that holds basic assignment info, and a table that joins them together for the log. As for the dates, we can slim that down to two and they are easy to maintain. Date started will get automatically updated on insert of new row and date of last submission will get updated whenever the record is adjusted. Date of completion we can get rid of because that will end up being the same as date of last submission. The only thing we may want to add is a completed flag.
So, let me post one more for the final vote on data needed.
Bill

[bill bozeman]

Data once again:
Students: studenID, firstName, lastName, dateRegistered, activeFlag
I vote we still keep activ flag in case someone posts there name twice or someone does an assignment once and then we never hear from them again. We'll default them to Y, but this is just an easy way to take them down if necessary.
Assignments: assignmentID, assignmentName, order, activeFlag
This is really just a reference table that really won't be touched much. Useful for our drop-down menus and general ordering of things.
Log: logID, studentID, assignmentID, dateStarted, lastSubmission, numberOfAttempts, completedFlag
Pretty easy to maintain database I believe and still easy to change or add things for the future.
Did I miss anything?
Once I hear from Daniel, Johannes, Marilyn, and Peter, I'll create a new thread for next steps. I think we can next break things out so someone is creating the SQL statements to create the tables and looking into the database and drivers needed, someone is creating the tag sets for XML (if we all agree that we want to do both solutions) and someone is creating the HTML look and feel of the table and the update pages.
Bill
[This message has been edited by bill bozeman (edited March 26, 2001).]

[Marilyn de Queiroz]

>Students: studenID, firstName, lastName, dateRegistered,
>activeFlag

dateRegistered on JavaRanch or date they started the cattle drive or date they added themselves to the log?

>I vote we still keep activ flag in case someone posts there name
>twice or someone does an assignment once and then we never hear
>from them again.

Good idea.

>Assignments: assignmentID, assignmentName, order,
>activeFlag

I think we don't need 'order'. If we change the order of the assignments the name will change (e.g. Java-1 Hundred will become Java-1 EvenOrOdd). So far names have changed from 1.1 -> 1.8 to 1.1 -> 1.4 and 2.1 -> 2.4 to Java-1 -> Java-8. OOP-1 -> OOP-4 used to be 3.1 -> 3.4 but the order has remained constant.

>Log: logID, studentID, assignmentID, dateStarted,
>lastSubmission, numberOfAttempts, completedFlag

I'm not quite envisioning the function of the completedFlag. If the student is on assignment Java-5, they will have completed Java-1 through Java-4. Will they all be listed in the table with completed flags?

>Did I miss anything?

Let me think about it overnight.

[bill bozeman]

dateRegistered
I was thinking date they started on the log. An automatic thing, but it would be pretty close to date they started the cattle drive (for new students)

order
The only thing I was thinking here, is if we were to change names again. Right now it is not a concern becuase the order would be the same as an alpha order. But if we changed names so it was just Java-Hundred and not Java 1: Hundred then we could still have a column that does the ordering. It doesn't seem like a big deal and it won't lock us into doing things by alpha order so allows it to change in the future if needed.

completedFlag
The log should only show the assignment they are up to. So as I just finished SortNames, the log for me would show Lookup even if I hadn't submitted anything yet. But what I was concerned with here was how do we know someone completed an assignment. For example, let's say you finished Say, and then decided to take a break for a week or so for some reason. I would think the log should show that you are on assignment Java 5, one after Say. But if we were to look in the database for a particular student and there last submission was on Say, we wouldn't know if they completed it or not. So in my eyes, it was just a way for us to know if someone completed an assignment or not.
However, this does bring up the point on how do you maintain that part. That would probably have to be updated by a nitpicker so someone couldn't say they are finished when they are not. Maybe that is too much. I'll rethink it overnight, but the above was my initial thoughts. I just feel we need something that tells you whether or not the user has completed it or not.
Bill

[Marilyn de Queiroz]

order
The only thing I was thinking here, is if we were to change names again. Right now it is not a concern becuase the order would be the same as an alpha order.

The fact that they're in alpha order now is just circumstantial. Other classes that are planned after these do not follow suit.

I was thinking that the Assignment ID would cover this, but it's not a big deal if we want a separate field.

[Marilyn de Queiroz]

I asked Paul Wheaton's opinion, and he said, "It sounds like an interesting project.

"If somebody builds it with servlets, we'll find a way to put it up.�

"I think a database would be overkill.� Personally, I would keep all the data in memory all the time and whenever somebody changes it, I would write it out as XML - and each time the program is started, read the whole thing in from the XML file."

[bill bozeman]

Personally, I would keep all the data in memory all the time and whenever somebody changes it, I would write it out as XML - and each time the program is started, read the whole thing in from the XML file

Uh-oh. A litte over my head. I come from the database side of things, so keeping things in memory and stuff like that is a little newer for me. Would love to learn it though
Let me ask you this though, do we want to keep any history of the users? My thinking of course is that we want to be able to keep a history. Wouldn't it be nice that after a year or so we can see how many students started the cattle drive, how many finished, how many dropped off after Java 1a or Java 4? I guess we can do that with XML also, but my thinking is we don't really want to delete or overwrite data as much as add data. But as I said, that is my experience, and you always speak to experience until you get new ones. So XML would be a new one for me.
Bill

[Johannes de Jong]

Yes it looks like it has come down to "to XML or not to XML".
I for one vote for XML. Daniel I had all intentions to look at it today but work got in the way . you really put in a lot of work, thanks for sharing it with me.
I would like to see the updating of their own status by the students as the main priority. I don�t mind doing it but its time that could be spent wiser i.e. figuring out Daniels code.
I don�t understand Paul's comment

"I think a database would be overkill. Personally, I would keep all the data in memory all the time and whenever somebody changes it, I would write it out as XML - and each time the program is started, read the whole thing in from the XML file."

Does this mean that the 1st person that calls up the assignment log will load the servlet ad with it the data (XML file) and the servlet will stay active in memory until a scpecified time period of inactivity i.e. no other user going to that page and as such starting up the servlet or what ??
I also haven�t really gotten any feedback from the "nitpickers" regarding the extra work my "design" would require from them. To me as a student it is important to know the status of my attempt, and from previous posting I think other students think the same. But that does involve work from the nitpickers. How do you guys feel about the extra work?
Bill I agree history should be included in the final solution.
Bill its your project whichever way you go and whatever role you have for me, I will accept you decision.

[This message has been edited by Johannes de Jong (edited March 27, 2001).]

[bill bozeman]

Thanks Johannes, but I really see it as all of OUR projects. I am used to doing things one way, but that in no way means that is the way we should go with it.
Let's do the XML solution. I have more to learn by doing it that way anyways. And we don't have to worry about trying to figure out how to set up the database.
I think you or Marilyn brought up the idea that the nitpickers will email the students a password where they can update the log when the finish a project. I think that is a good idea and we should keep that in mind. That way the nitpickers don't have to go in and give the person rights everytime they pass an assignment.
I'm going to start a new thread so we can discuss the tag set we need for the XML pages. Daniel, I am like Jo, I haven't looked over everything you have done yet. I'll do that today.
Jo, as far as your ideas. I like them and we will talk about them more in the next phase of things. For now, let's just get it to where users can update things themself and then we can talk more about next steps.
Bill

[Wirianto Djunaidi]

I'm excited to hear about this project and XML stuff,
since I'm starting learning XML myself.
Anyway, here are some thoughts about the project:
How is the XML going to be used? I'm kind of hesitate on
having the XML stored in memory, it will create more complication
since you have to keep track on the active time and swapping
it into storage(either file/database) once it's not needed.
Also, for the front end, are you going to parse the XML yourself
and generate an HTML tables or just dump the XML and use XSLT
to format the the look?
It might also be a good idea to checkout Jato - http://www.krumel.com/jato
It's a tool that can convert XML to Java Object and vice-versa.
Save a lot of times and headache of parsing the XML tree yourself.

[Daniel Olson]

Originally posted by bill bozeman:
Let's do the XML solution. I have more to learn by doing it that way anyways. And we don't have to worry about trying to figure out how to set up the database.

I don't think it has to necessarily be either XML or a database. We can start with XML and as we add complexity in later phases we can have a utility class with methods that retrieve data from XML sources and other methods that retrieve data from a database. The methods could create an XML document in memory with the data and that could be how the Java interacts with the data no matter where the data comes from. The servlets that display the data can be ignorant of whether the data is coming from an XML file or a database. The data can be saved in the same way.

[Johannes de Jong]

See http://www.javaranch.com/ubb/Forum19/HTML/000379.html for the XML part of this project
[This message has been edited by Johannes de Jong (edited March 27, 2001).]

[Junilu Lacar]

Hi All,
Looks like everybody is all excited about this project and are chomping at the bit to get something started.
Before getting ahead of ourselves though, may I suggest that we get an overall plan of attack together first. There's been talk about phases: Phase 1 and 2, etc. There has also been a date mentioned: April 27 (my birthday, BTW ) to find a project leader. There has also been discussion related to design (lots of it already done). And it's all getting a little bit confusing to follow.
Here's what I propose:
1. Define what features should be in Phase 1. Johannes can play the CUSTOMER. Johannes, you specify features and prioritize them according to their importance to you and the nitpickers. That means that you can't do any of the development or design though. You have to steer the development from a BUSINESS VALUE point of view.
2. Get a development team together and have each one sign up for tasks. That keeps everybody interested and committed. It might help if developers sign up in pairs. And developers don't get to specify any features. If they want, they can run their ideas by Johannes. If Johannes likes it, he can request that it be included in the plan.
3. Start new and separate threads to discuss: Planning (releases and iterations), Features, Functional Tests, Design Issues, and Unit Tests + Code, Deployment. That way, we don't get things all mixed up and the discussions can stay focused.
I agree with the idea of keeping things simple at first then add complexity as we go along. The first iteration would probably be just a skeleton (comprised of stubs) of the features we eventually plan to include in the first release. Second iteration would flesh it out a little bit. The third, a little bit more and so on.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 07, 2001).]