Note: this page is still under construction, so new content or clarifications to existing content may be added; however, the current content will not change significantly without notice.
This page will go over the structure of our projects (both the webpage and the code). First things first: each project/part assignment page will include the due date at the very top, as well as a link to a form that you'll need to fill out if you want to submit late.
(Note that some of our projects have multiple numbered parts, each with its own due date and webpage, whereas others have no numbered parts and only a single webpage and due date. For the sake of brevity, we'll refer to anything with a distinct due date and webpage as an "assignment" for the rest of this page.)
Afterwards, we'll provide a brief summary of the purpose of the assignment. Some assignments will just involve implementing data structures, whereas others will involve implementing applications that use those data structures.
NOTE: Because our applications build off of our data structures, you should take care when implementing these data structures—if your data structures are buggy, you will end up with strange and difficult-to-debug issues in future parts. When you get feedback for each assignment, make sure to fix the issues listed before starting on the next assignment.
Below that will be two lists of files: files you will modify and files that are generally helpful in looking through as you complete the assignment. For example, this is the file you need to modify for homework 0:
main/java/misc/HelloWorld.javaNote that these file paths are relative to the src folder in the code. Now, here
are some files that may be worth looking through while implementing the file above, but that you
don't need to modify:
test/java/misc/HelloWorldTest.javamain/java/misc/sanity/SanityCheck.javamain/java/misc/exceptions/NotYetImplementedException.javaThis second list will not necessarily be exhaustive, but should provide a good starting point.
Sometimes, we will also include another section going over the expected final behavior of our code to put the rest of the instructions into perspective.
The instructions for each assignment are broken up into sections, each describing a task you'll need to complete in the assignment.
Since our assignments are dependent on each other, the first part of the assignment will often involve copying over relevant files from the previous project.
Our instructions for each section will provide a high-level overview for the classes or methods you will be implementing. We encourage you to read through the entire assignment page to get a solid understanding of all the sections before attempting to start writing code.
We'll also take this moment to note that not all sections will take the same amount of time and effort, so if you are working with a partner, it is not a good idea to divide and conquer separate sections. Instead, we strongly recommend pair programming—this will ensure that both parties contribute equally and that both parties know what the code does and how to debug it when using it in later assignments.
More specific details about implementation and particular methods will be located in the relevant source and test files themselves. Carefully read through the comments and test files to confirm your understanding of behaviors. This will help you plan and fix your implementations.
For any project unless otherwise stated, you may not...
java.util, except for the following cases:
java.util.Iterator.java.util.NoSuchElementException.java.util imports in your test files.Several times throughout the quarter we will ask you to write additional unit tests for your code, and we will grade how well these unit tests are designed. (Check out the project grading page for more details on test grading.) There are two types of test files we will ask you to write:
All tests are required to include some timeout. If any test does not have a timeout, we will add one of 15 seconds; otherwise, tests may run infinitely and nobody will get grades.
In assignments with applications, there will be many application-specific files outside of
the datastructures Java package. Other than the files we mention may be useful at
the beginning of the assignment page, you should not need to poke around in these files much. In
general, if you find yourself needing to dig through more than a few of these to complete the
assignment, you should consider coming in to office hours for help. Of course, you're also free
to look around if you're curious about the application implementation.
For all assignments, you should modify only the files we explicitly list at the top of the assignment page as needing modifications. All changes in other files will be ignored during grading. If you accidentally change one of these files, your code may not compile when we're grading, in which case we may not grade your code, and you'll get a zero on the assignment. If you need to temporarily change one of these files for debugging, make sure you revert your changes afterwards.
Also, absolutely DO NOT change the gitlab-ci.yaml config file. This file
affects what the GitLab runners run; you have no reason to change this, and if you do, you may
lose the ability to get feedback from the runners. Also don't change the
build.gradle file, since your IDE needs that check project dependencies.
Our GitLab repos will have runners set up to automatically check that the code in your repository compiles and passes checkstyle and that your tests pass. If everything is fine and all the tests pass, you'll get a green ✓ on your repo homepage; otherwise, you'll get a red ×. Check out this gif for a demo of how to find the runner's output in this case to see what went wrong.
Note that the runners will not be used during grading. They serve mainly as a sanity check (to make sure your code is pushed to GitLab properly) and as a benchmark for efficiency tests (the machine we use for grading should be more powerful than the ones the runners use, so you should aim to make your efficiency tests pass on the runners).
Additionally, the runner machines are shared with other courses, so we cannot guarantee that the test results are always accurate. In general, they tend to run slower towards deadlines, when everyone is pushing their code, so we recommend that you start early if you wish to make full use of the runners. This also means that you should NOT depend on the runners instead of running tests or Checkstyle locally.
If functionality tests sometimes fail on the runners, but consistently pass locally (and you've correctly pushed all your code to the runners), it's safe to assume that your code is fine and that the runners just are running slowly. However, if efficiency tests sometimes fail on the runners, you may want to consider optimizing your code.
Also, the runners will only check your code if you push a commit that changes your code; changes to other files will not trigger the runners, which means you will not see a ✓ or ×.
Submit your code by simply pushing your code to GitLab before the assignment is due. You don't need to do anything else; we'll pull your assignment repositories at 12am when the assignment is due (and on the following days for late submissions). Feedback and raw scores will be pushed back to your repos after we're done grading. We'll also push a tag to the repo marking which commit was graded. For extra credit, make a note of it in your writeup.
Once again, if you will be submitting late, you must fill out the late submission form to tell us which commit to grade. If you do not, we will assume that your submission is on time and grade according, and you will not be able to change this after we've finished grading.
For groups with more than one person, only one person needs to fill out the form, and a late day will be deducted from each member. Also, submitting an individual write-up late does not require filling out this form, and will count against only the members who submit late on Canvas.