Coursework Basics

This page contains information that is common to all the exercises and programming assignments, and which you may find useful as you work through them.

Getting the assignment’s files

Every assignment has a series of files you will need to complete the assignment, including some skeleton code as well as the automated tests for the assignment.

So, before you can start working on an assignment, you will need to get those files into your git repository (please note that it is important that you complete the first lab to learn the basics of git before you start working on your first programming assignment).

To get the files for a programming assignment, change to your capp30121-aut-20-username directory (where the string username should be replaced with your username) and then run the following commands:

$ git pull
$ git pull upstream master

The first command just ensures that your local copy of your repository is in sync with the server. The second command is the one that actually fetches the instructor-provided files. Instead of pulling from your own repository, it pulls from a special “upstream” repository set up by the instructors.

Files for the exercises and programming assignments will appear in a exN or paN directory, respectively, where N will be 1, 2, 3, etc. (i.e., ex1, pa1, ex2, pa2, …). The directory will include a README.txt file with a description of the files contained int he directory. Make sure to always read this README.txt file.

Please note that it is always good practice to run git pull upstream master before you start working, as this will fetch any updates to the instructor-provided files. For example, we may occasionally update files if we notice bugs in our code, add helpful new test cases, etc.

Using git

Once you’ve fetched the assignment’s files, you can proceed as described in the first lab: work on your code and then run git add <filename> for each file you change, followed by git commit -m"some message" and git push to upload your changes to the server.

We suggest you add/commit/push every time you complete a specific piece of work, or once you’re done working for the day, so there will be a backup of your code in the Git server. Your commits should describe the work that you did as part of that commit, and should look something like this:

  • Finished Task 1

  • Made progress on Task 3, but not yet done

  • Fixed bug in Task 2. All tests pass now!

You should also make sure to run git pull and git pull upstream master before you resume work to retrieve the latest files. This discipline will guarantee that you always have the latest version of your code, no matter which machine you are using. Also, it will be easier for us to help you recover from git and chisubmit problems if you consistently push updates to the server.

That said, you should avoid using Git as a mechanism to synchronize your code across multiple computers. More specifically, let’s say you’re working on your own computer, and need to upload your files to a CS server to run the tests. You should not do this by pushing your code to the Git server from your computer, and then pulling it from the CS server.

In other words, if you find yourself frequently committing code with messages like “Uploading to CS server”, “Changing file to try on CS machine”, etc. and doing this multiple times while you’re working on your code, this is not how version control systems are meant to be used. A commit should represent a meaningful change in your code, and should not be used as a mechanism for copying files to another machine.

At the start of the quarter, we recommend that you simply work directly on a CS environment (e.g., by using the Virtual Desktop system). Once you’ve developed more comfort with using Linux, you can switch to working on your own computer, and using SSH to copy files from your computer to a CS server. You can find instructions on how to do this on the CS Techstaff’s website (see “File Transfer” in their Remote Access page). You can also set up you code editor to this automatically for you (see the “SSH access from a code editor” in the Working Remotely page of the CS Developer Guide)

Using IPython

It is important to experiment with library functions and try out your own functions by hand in ipython3. When starting IPython, you should make sure to always enable “autoreload”:

$ ipython3

In [1]: %load_ext autoreload

In [2]: %autoreload 2

The commands %load_ext autoreload and %autoreload 2 tell ipython3 to reload your code automatically whenever it changes. We encourage you to use this package whenever you are developing and testing code.

Getting help

If, after carefully reading the details of any part of an assignment, you are still confused about how to get started or make progress:

  • post a question on Piazza to ask for help, or

  • come to office hours, or

  • make sure to attend your discussion session for additional guidance on the programming assignment, or

  • see the CS “Harper Tutors” who are available in North Reading Room of the Arley D. Cathey Learning Center on Sunday through Thursday evenings from 7pm to 11pm.

Before you post a question on Piazza, please check to see if someone else has already asked the same question. We especially encourage you to check the “Must read posts for PA #1” post, which we will update over time to be a compendium of important questions and answers. Also, please read the pinned post on “Asking effective questions”. Please note that you should never post code or screenshots to Piazza. Finally, always remember to add, commit, and push the most recent version of your code to the server (as described above) before you ask your question. Syncing your code will allow us to look at it, which may speed up the process of helping you.

Style

Following a consistent style is important because it makes it easier for others to read your code; imagine if you were collaborating on a large software project with 30 other developers, and everyone used their own style of writing code!

To help you understand what constitutes good style, we have put together a style guide for the course: `Python Style Guide for Computer Science with Applications. <style_guide_>`_ We expect you to use good style (that is, style that matches this guide), and will take this expectation into account when grading