One of the most difficult parts of the organization and administration of these assignments is trying to make fair assignments of credit, where credit is due. We do have access to tools to check files for duplicate work, but I hope they'll rarely succeed in finding any! Let me put it simply: The more you copy, the greater chance you'll get caught and get a zero, or worse; the less you'll learn and the worse you'll do on tests; the less you'll learn which will make future courses and jobs more difficult to deal with. (I have spoken recently with people in the industry who have to decide whom to lay off. The people who have the least skills are the first to go. The more you do on your own in this course, the more you'll increase your skills.) I have occasionally been suspicious of good machine problems handed in by students who then do poorly on tests. When called into my office to discuss and explain their machine code, they sometimes fail miserably and eventually admit that they did not write the code they put their name on and handed in. I don't want a single one of you to put yourself in that embarrassing position. So do your own work. It may be a frustrating struggle in some cases, but, "No pain, no gain." -- there's truth in that.
Also, see the Projects page.
Most of the assignments will be handed in electronically. You MUST always put your assignment materials in clearly labeled directories and email both Professor Futrelle, futrelle@ccs.neu.edu and also to Ms. Jing Shan, the teaching assistant jshan@ccs.neu.edu. And of course, your email must be clear and clearly labeled as to who you are, your name and ID number, what assignment you're handing in, which group you're in, and what other people you are working with. If you work quite closely with someone else in your group, you MAY NOT hand in identical files -- too often this results in less work done by each person involved and often in one person in a group doing a lot more than the others and others doing a lot less. So what differences do we expect to see? We expect to see similar APIs but quite different Javadoc comments and internal implementations of the code from every student. The APIs must eventually be identical if all the code in the group is to work together. But of course the APIs in different "phone companies" will be different.
All files need to be accessible on the CCS Unix system. You may develop your code elsewhere, but it must compile and run under CCS Unix. We strongly prefer that most of your materials be put in your web space so we can simply click on them in our email and have them appear in a browser, as opposed to having them included as attachments that we have to open and store in our systems as files and open in one or another application. See for example, source code for the Demo1 project that can be pulled up in your browser with this link. If you happen to be adept and building web pages, you can simply give us one URL for your assignment(s) and we can browse web pages that you have constructed that bring together your code. You will not receive additional credit for doing things in this way, since this is not a course on HTML, but such an approach would be most appreciated! And of course your pages can be in "hidden" directories, so only we can access them.
For executable code, you'll need to arrange to have any directories (preferably "hidden" ones) writable in case any of your code writes to files when it runs. Then, we can run your code to check it. You're welcome to include files of output from your running code where you have print statements. (Check out the Unix shell redirection operator, '>'.) If all URLs and directory pathnames are spelled out in your emails or web pages, then our access to what you've done becomes about as efficient as it could be. Since Professor Futrelle and the TA are dealing with a total of 100 students this Spring, efficiency is important if the grading is to be thorough and fair.
Hopefully, the four "phone companies" will be organized this week and you can work with other students on this first assignment. If not, you should do the work on your own and hand that in. What you produce will be very similar in style and organization to the Demo1 project I've created. You are to do the following:
Your Javadoc comments: In some cases you may want to make your comments lengthier than in the examples I gave you, in order to clearly spell out the details. Also, look into using the @param tag which allows you to specifically describe method parameters. Furthermore, note that Javadoc treats the first sentence of your comments differently from the rest. It is used in the shorter summary description of the class and member descriptions. (See this note about the first sentence of a Javadoc description.)
Running Javadoc (command-line options): Here is the typical command line that I use to run Javadoc:
javadoc -version -author -private -d ~/.www/1204/a1/jdocs/ -windowtitle "R. Futrelle 1204 Evap example" *.javaThe files this javadoc command produced can be accessed at http://www.ccs.neu.edu/home/futrelle/1204/a1/jdocs/index.html. They were run on the evap example.
Explanation of the options I chose:
Your CCS web directory: Be sure to see http://www.ccs.neu.edu/webadmin/personal.html that explains how your web directories should be set up on the CCS unix machines -- what the CCS web server will look for and how you can refer to your directories, etc.
Your Java source files: We would like to see your source files and even run the compiled versions of them. In order to do this, you need to put your files in a directory that we can access. If your runs produce printed output, which they probably should, that can be redirected into a file that we can look at.
What you should email us for your assignment: Please include the following information in your email, addressed to jshan@ccs.neu.edu and futrelle@ccs.neu.edu.
Return to Prof. Futrelle's home page