Regarding Graphic Software Packages
Project Submission Guidelines
Our project submission model is similar to that of a client-company relationship. The TA is your client, and you are the CEO of a one man software company (well, for now). Your client gives you the specification of the software products he expects you to design for him, in the form of the project assignments. Your job is to deliver your software on time and make sure that they fit the description outlined in the specifications.
You, as a company CEO, have the greatest freedom in choosing the computer language(s) (C, C++, Java or C# in this class) to implement your projects, and most importantly, the way you wish to implement your company's products. In exchange for that freedom, you have the responsibility to assure your client, the TA, that software you write can be successfully installed on his computers, i.e., computers in the CS lab. The TA can be as uninformed as clients in real business worlds (he is not of course!), and it is always your job to educate him so that he knows how to compile and install your software product on his computer. Your advantage is, you do have the chance to access machines the TA uses, i.e. the CS lab, to make sure your code really works before you submit it.
If your client cannot use your software for any reason, it is most likely your fault. In the real business world, you cannot argue with your client, or you will lose your business. What you can do is to make it as simple as possible for the TA to install and test your software. If you choose some unusual platforms to implement your projects that are available only to you, you will need to port these codes to the TA's machine in order for him to evaluate your software. For example, you can use your fancy Java development platform on your PC to develop the projects, but you need to make the resulting code executable on the CS lab machines.
Having said these general principles, the following are more specific instructions on what you should do to get your projects submitted, and hopefully get good scores from your client, the TA.
1. Submission method
To submit your project, run the program ~cs440/bin/submit on a CS workstation, give the project number and a list of project file names as arguments to that program, like below:
~cs440/bin/submit 1 foo.c foo.h Makefile README test.data
...
If you have put ~cs440/bin in the search path of your shell, you just need to type, "submit". Note that the submit program will not accept directories. This is to prevent accidental submission of the /. To submit a whole directory tree like the Java classes, tar your directory trees before submission.
It is your job to transport your files from whatever machines in your dorm, your home or your laptop to the CS lab machines in order to submit them. This can be achieved through uploading, downloading (depending on which end you run your ftp client), or by way of the diskette, CDR, DAT, etc. No matter how you get your files there, make sure the TA has the complete collection of files needed to build your executables.
You can run the submit program as many times as you wish (well, be reasonable; the System Administrator may not be very happy if you submit a file every microsecond), on just one file or many files, and before or after the deadlines. You will be notified by the submit program if your projects are late. Files you submitted before will be overwritten by files you submitted later having the same names. The submit program just keeps the latest version of each file you submitted.
2. Files that should be included in your submission
As said in the preamble, you should treat your TA as your client, so you need to provide as much information as possible in your submission to tell him how to build your programs. Usually, you should include at least a README file that provides your name, your SSN, and detailed directions on how to build your code from the source files you submitted. Actually, you may wish to include a Makefile so the build process can be made a no-brainer. If your program has some fancy features that are not immediately noticeable, you may also wish to mention that in your README file. The README file will be like a user manual to the TA, so don't hesitate to write more if you wish to make sure the TA knows how to use your software. Don't forget to include all supplemental files, grammar files, header files, or test files with your submission, if they are relevant to your projects. Also, you may want to include a copyright notice file to declare who owns which part of your software, as many free libraries such as X11 require that. See copyright issues below.
3. Files that should NOT be included in your submission
Only source files and appropriate auxiliary files for making your executable code should be submitted. Do not send in object or executable files. They will be ignored. Definitely do not send in core dump files, since they are bulky and take up lots of space. Actually, the submit program will refuse any file bearing the name "core". If you accidentally typed "submit 1 *" after working hard for 24 hours to beat the deadline, and you realize that you have submitted junk files as well as good files, you should write an email to the TA explaining that you are just being exhausted for doing that. I am sure the TA will understand and help you clean up the mess. Please remember, however, there is usually a 10% aesthetic score regarding each project, which includes judgment by the TA on how you manage your files and the submission process.
4. If the TA has problems making your files
The TA will send you emails asking your help to make the executable code if he fails to make it based on your README directions. You will be given an opportunity to demonstrate how files you have submitted can make a good working program that runs on the TA's machine. You will not be allowed to supplement missing files after the deadline unless you are willing to take the late submission penalty. If the problem is related to the specific platform you have chosen, as said before, you will need to solve that problem yourself. The TA will not be obliged to port any unavailable software you have chosen to implement your projects to the CS lab machines.
5. If you have a dispute with the TA
After you have tried your best to convince the TA that you have done your project but he still fails to compile your project successfully on his machines, or if you think your projects have not been graded fairly in any aspect and you also have failed to convince the TA with your beliefs, you can bring the issues to the Instructor for consideration. The Instructor will try to listen to your story, and also the opinion of the TA. He will make a decision later whether to buy your story or to stand by the TA's decisions. This will be the final verdict. In any case, you should act professionally, reason with courtesy, and argue with good manners. Both the TA and the Instructor are there to help you, as long as you are reasonable.
6. Copyright issues
One of the goals of this class is to train you in good software engineering manners, such as acknowledging the work of others. Many software platforms, such as X11 or Java, are developed by others. The authors allow you to use their software platform and libraries for free, but they usually ask you to acknowledge their copyright by including a notice in your distribution. There is a sample of such a copyright notice in ~cs440/pub/trend/copyright.h. You should probably follow the tradition.
Also, you should grant the Instructor and TA rights to read, demonstrate, modify, compile, execute and archive your codes for academic purposes, including but not limited to, distribution and publication for future students. Your identity will be stripped from your codes to protect your privacy. Your use of the submit program implies that you agree to these terms. You retain the title of your code for your future use, except the part that's directly originated from the project descriptions, which are copyrighted by the Instructor. We will keep an archive of your files indefinitely to compare against future class project submissions in order to prevent academic dishonesty. If you do not agree with this licensing arrangement, you should talk to the Instructor.
That's all, folks. If you have any further questions regarding the project submission guidelines and processes, or you find any bug with the project submission program, you can contact the Instructor.