Assignment 00
Assignment 01
Assignment 02
Assignment 03
Assignment 04
Assignment 05
Assignment 06
Assignment 07
Assignment 08
Assignment 09
Assignment 10
Assignment 11

How to Submit Assignments

Assignments will direct you to submit one or more files. For a given assignment, this means you will need to:

• Create an assignment directory within the cs383 directory on your account on the Edlab. It should be named assignmentXX, where XX is the assignment number. For example, the first assignment’s directory should be named assignment00.

• Before the due date, create or copy the file(s) required by the assignment into the assignment directory.

I have a program scheduled to run at the due date. It will copy the contents of the assignment directory as it exists at that moment into a separate directory for me to grade.

If you do not name the assignment directory correctly, then it will not be submitted. If you do not locate the assignment directory within the cs383 directory, it will not be submitted. If you change permissions to make it or its contents not readable to the cs383 group (which only the TA and I are members of, not your fellow students), then it will not be submitted.

Since there are 50+ students enrolled in the course, I have to use automated tools as part of the grading process to get it done in a reasonable amount of time. To ease the automation I need you to follow the submission directions exactly. Before you’re done with each assignment, take the time to check that you’ve followed the directions exactly, paying special care to filenames and output format.

Some advice

Start assignments enough days in advance that you can ask for help (or an extension, if need be). In particular, Patrick and I aren’t up all night Thursdays at the ready to answer questions, nor are we necessarily available moment-to-moment on Fridays.

If you start the assignment, and realize something is just fundamentally not making sense to you, ask for help, either from me, or Patrick, or one of your fellow students.

When talking with Patrick or me, bring (or include in your email) your source code and other artifacts showing partial progress so we all are on the same page.

Restrict your discussions with other students to broad concepts or specific examples: don’t share or copy answers or simultaneously solve the entire problem together. This applies equally to programming assignments and assigned exercises/problems.

Test your programs. Don’t just test against a single case; make sure that you test against a variety of inputs. And by “test,” I mean construct a test case where you pre-specify the input and output(s), then verify that they match. This is easiest to do programmatically, with the bonus that you can run the test repeatedly and quickly as you modify your source code. At the risk of telling you something that’s already been pounded into your head back in 220 or 230, this is called unit testing when done on a function-by-function basis, and integration (or system) testing when done at a larger scale. There are tools and frameworks to help you automate testing, which is an awesome thing you should get in the habit of doing generally.

Keep your programs in a revision control system. When answering questions and interacting with students in previous classes, I’ve been told numerous times some version of “I made a change and everything stopped working, but now I can’t figure out what I changed.” Having done this myself, I understand it’s immensely frustrating. But it’s also entirely preventable. Get in the habit of using Subversion, Mercurial, Git, or some other version control system, committing every single time you make a logical change or set of changes, and identifying these commits by a meaningful comment. You don’t have to deal with the distributed aspects of some of these systems. Just store your code locally. Further, you don’t have to deal with the command line. Many IDEs have full support for one or more version control systems, and most VCSs also have GUI frontends you can use. I’ll never code anything but the most trivial of one-liners again without a VCS.

Practice debugging. Learn to use simple technique like adding print() statements everywhere that you’re not 100% sure about variable values or control flow. Learn to use more complex tools like your language’s debugger and/or other static and dynamic analysis tools.