Coursework

Course Format

The course consists of a mixture of lectures, homework, and a final project. Lectures, lecture exercises, and most homework will be provided through Jupyter notebooks. Details on each course component can be found below. All course work will be hosted on your private GitHub repo.

Course Workflow

All of your work (except for the class project) will be hosted on your private GitHub repo named githubusername/cs107_<firstname>_<lastname>. (Please use all lowercase letters!)

It is critical that you set up a private repo (free for students) and give the teaching staff github account (cs107-sys-dev) access to your private course repo. There are two reasons for keeping this repo private. One is so that other students cannot see your work. The other reason is because the teaching staff will be providing comments and you may not want other students to see these.

Before arriving at each class, you should download the lecture to your local computer, copy it to your course repo, and push the changes to your remote course repo. Even though you will be able to see the lectures on the course website, this procedure will make sure you have an up-to-date personal course repo that accurately reflects the course content. This may be helpful for your future records.

Deliverables for this course will be submitted via Github (see below for exact instructions). Make sure you push all changes to your repo before each deadline. The teaching staff will check out your latest work, grade it, provide comments. We will be able to see if you've submitted your work on time or not.

Course Repository Structure

Your private Github repo should have the following structure:

The class project will be done in groups of 3 to 4. You should create a GitHub organization with your group members and add the teaching staff to it. The organization will be called cs107-groupname and the project repo should be called project. The group is free to make other repos within the organization for experiments, but project is the one we will grade.

Project Repository Structure

Your project Github repo should look similar to the following:

A Note on Jupyter Notebooks

Jupyter notebooks are great for code prototyping and learning how to use new features and APIs. They are also wonderful for creating documentation and interactive reports and even delivering lectures. However, they should not be used for large software development projects! One reason for this is because code development in Jupyter notebooks represents a nonlinear development process. Another reason is that there is presently no good solution for version control of Jupyter notebooks.

Therefore, in this class you must turn in all homework in Python (.py) files (or .cpp files if you choose the C++ modules). You are also encouraged to do your main code development in a text editor or the interactive development environment (IDE) of your choice (e.g. Spyder). Homework assignments and lecture exercises turned in with Jupyter notebooks will not be graded.

A homework workflow is outlined in the Homework section.

Lecture Format

The lecture format for this course consists of a combination of synchronous and asynchronous approaches. The basic structure is as follows.

Live Lectures

Live lectures will be delivered on Tuesdays and Thursdays. Live attendance at these lectures is optional although strongly encouraged. The live lectures will each take 75 minutes and will consist of a mixture of instructor content delivery (lecture) as well as interactive discussion sessions. These live lectures will be recorded and posted to Canvas after class. To encourage participation of students who cannot attend live lectures, the recorded lectures will consist of embedded "quizzes". These quizzes will not be graded, but will be important to test your comprehension before moving on to the next portion of the lecture. If you are unable to attend the live lecture, then you must watch it before attending the pair-programming sections.

Pair-coding Sections

Pair-coding will form an essential part of the course. Pair-coding will take place in mandatory pair-coding sections led by members of the teaching staff. A schedule for the pair-coding sections will be released in the first week of class. The sections will be offered at a variety of times to accommodate students in different time zones. The first pair-coding section of each week will take place on Thursday. You MUST attend at least one pair-coding section each week. You are free to attend any section that you desire in any given week. During these sections, you will work on coding exercises that will build upon the concepts covered in lecture. The exercises will be released to the course website on Thursday each week and solutions will be released one week after the final pair programming session for that cycle. For example, the exercises will be released on a Thursday and pair programming sections will be held on Thursday, Friday, and Monday. The pair programming exercises will be due one week from that Monday no matter when you attended the section. You must turn in your excercises (to your private Github repo) no later than one week after your pair-programming section. The teaching staff will grade exercises for completeness. Since you will be pair-programming with partners and with members of the teaching staff, these exercises are almost free points. Please complete the exercises! Don't worry if you didn't get them perfectly correct.

Exercises performed during pair-coding sections should be put under version control similarly to how homework assignments are versioned (see Homework section below). The pair-coding exercises must adhere to the following directory structure:

• Your private Github repo should contain a directory named pair_programming with subdirectories for each session. The subdirectories should be named PPn where n is the session number.
• Within the subdirectory PPn, place the exercise files that you completed during the pair-programming sections. The exercises must have the name exercise_m.ext where m corresponds to the exercise number and ext is the proper extension (.py, .sh, .c, .cpp) depending on the exercise.
• Remember: These exercises will be mainly graded for completeness and to make sure you are on the right track. Please carefully follow the required repo structure. That is the easiest way to get full points.
• A sample Githup repo is shown below:

Pair-coding workflow

There are many pair-programming solutions available. Unfortunately, many of them require payment plans and/or only work with a specific IDE. One of the best solutions so far appears to be from Deepnote. We will use Deepnote this semester for all of your pair-programming excercises. You should sign up for an account right away (Join Sys-Dev Deepnote Team)!

Deepnote is really marketed for those using Jupyter notebooks. However, it also comes with a terminal so you can work from the command line. I request that you resist the temptation to work in notebooks. Remember, in this course, we are doing everything from the command line and writing all our code in text files (.py or .cpp as appropriate, and sometimes .sh.).

Required Deepnote Project Structure

• Create a Deepnote project called cs107_pair_programming (or ac207_pair_programming).
• Open a terminal inside that project.
• Create a directory called PPn where n is the number denoting what pair-coding exercise you're working on. For example, if you are in the very first pair-coding session, create a directory called PP1.
• Do the exercises inside that directory. For example, create a .py file called exercise_1.py if you are working on the first exercise. You can run the code from the terminal as if you were working on your own computer.
• When you are done, download the exercise to your local computer, move it to your private repo, and push to Github.
• A sample Deepnote project is shown below:

• In each pair programming session, you will give your partners access to your project. Click on "Share", "Manage Collaborators" and give "edit" access:

Required Pair-Programming Protocols

Now that you have created a nice Deepnote project, it is time to understand how to do some pair-programming. The exerises in the pair-programming sections are necessarily collaborative. In fact, each member of the group will turn in the same script! How is this fair and how can this possibly work? Follow the structure below:

• For each exercise (or sub-exercise for big problems), there will be one sharer, one coder, and one listener. This assumes a group size of 3. If the group only has two people, then either one of you can take the sharer's role.
• The sharer will start each coding session and document interactions including points of contention and challenges. The coder will be in charge of writing the code. The listener will make suggestions and may offer tweaks from time to time.
• Each member of the group will have a version of the exercises for that day in their Deepnote project.
• The sharer kicks things off by opening the .py file for that exercise in their personal Deepnote project and sharing the exercise with their team members. Make sure you give each partner access to "edit".
• After the team members have accepted this invite, they will be able to see the exact same file that the sharer has open. They will also be able to make direct edits to that file.
• The team should discuss a strategy on how to approach the exercise.
• The coder should start writing some code with input from the other two team members.
• Before each section that you work on, place a comment indicating which team member worked on that section.
• Example:
• For small exercises, each team member can play a single role.
• For large exercises, the team members may rotate roles. The exercise will make it clear when you should rotate.
• At the end of the exercise, all group members should download the completed (or nearly complete) code from Deepnote and upload to their respective private repos. Note that the excercise code will contain comments pertaining to who worked on which section.

C++ Modules

For those interested, we will be offering C++ modules on selected topics. These lectures will be delivered immediately after the regular lecture period. The C++ schedule can be found in the figure below. C++ lectures will be announced in advance of their delivery so you can plan. They will be recorded and posted to the Canvas site along with the regular lectures. The content in these lectures is NOT mandatory. You can elect to study it or not. You may also choose to do your homework assignments in C++ or not. You can choose to do some homework assignments in C++ and others in Python. However, you must be uniform in your language choice throughout a given homework assignment. For example, if you choose to do HW2 in C++, then you must submit HW2 in its entirety in C++. Homework assignments completed in C++ will get an automatic +5 points to account for the enhanced difficulty. If you choose to do your project in C++, then your final project grade will be adjusted to reflect the additional difficulty / ambition. The figure below shows a basic course timeline with the optional C++ excursions.

Dr. Andrew Kirby will deliver the C++ lectures. He will also be available for C++ help sessions.

Homework

There are 7 homework assignments. The homework will be released on Tuesdays and due at 11:59 PM Boston time two weeks after they are released. Exceptions to this policy will be announced in class and can be seen on the Course Schedule. Specific instructions in each released assignment override these instructions.

• Homework is worth 20% of your final grade.
• Your private GitHub repo should contain a homework directory with subdirectories for each homework assignment. The subdirectories should be named HWn where n is the assignment number.
• Within the subdirectory HWn, place the assignment files that you want us to grade in a directory called HWn-final where is the assignment number. We will only grade appropriately-labeled assignments!
• To emphasize proper Git workflow, all of your homework assignments will need to be completed on Git branches other than master. You will then need to make a proper pull request and merge from a development branch, called HWn-dev, into your master branch. Please see the example below. You will lose points if this workflow is not followed.
• New homework will be assigned on Tuesday and are due on Tuesday night at 11:59 PM (Boston time) two weeks after their initial assignment.

Grading Scale

Homework will be graded on a 100 point scale:

• 100 = Solid / no mistakes (or really minor ones)
• 80 = Good / some mistakes
• 60 = Fair / some major conceptual errors
• 40 = Poor / did not finish
• 20 = Very Poor / little to no attempt.
• 0 = Did not participate / did not hand in

Homework Sessions

In an effort to foster community in this remote-learning environment, the teaching staff will offer special homework sessions. These sessions will not be office hours per se. Instead, they should be used by students to get to know each other, discuss the homework assignments, and help each other out. Homework assignments will usually contain a few discussion questions to help spur conversation on concepts from the homework. Members of the teaching staff will be present at these homework sessions to help organize participants and guide the discussions as necessary. The homework session schedule will be released in the first week of class.

Example Homework Workflow

The easiest way to understand the assignment workflow is by example. We provide an artificial scenario below, which you can use as a template for all homework assignments.

Note: Specific instructions provided in each homework assignment override the following instructions.
Note: The following workflow will count for 10 points of each homework assignment.

Suppose homework assignment 3 consists of 4 problems.

Homework Setup

• Make sure your master branch is up-to-date.
  • Use the git pull to update your local master branch so it is in-sync with your remote master branch.
• From your local master Git branch, create a new development branch called HW3-dev.
  • Use the git checkout command to create a new local development branch.
  • We will only be grading the work you do on this development branch. You will lose 5 points if you do not do your development on the HW3-dev branch. You are free to make other branches off of HW3-dev, say for individual problems, but you are responsible for making sure you merge these additional branches into the HW3-dev branch.
• Within your homework/ directory, create subdirectory HW3/.
• Under the HW3/ directory, create subdirectory HW3-final/.
• Only files within HW3-final/ will be graded. HW3-final/ should consist of one python file for each problem:
  • P1.py, P2.py, P3.py, P4.py
  • Each file should run and return the required output.

Local Development

• You can now do all of your development within your HW3/ subdirectory on your HW3-dev branch. As you create and change files, please commit early and often to your development branch.
  • Use the git add <file_name> command to stage files you have changed for a commit.
  • Use git commit to create a commit & message for your repo.
• Once you have begun some local development, it is a good idea to push your local development branch and current progress to your remote Github repo.
  • Use git push to push local branch/commits to your remote repo.
• You may want to undo changes/commits you have made for some reason, say if you find a bug in your code.
  • Use git checkout -- <file_path> to undo changes to a single file.
  • Use git revert <commit_SHA> to undo the changes in a specific commit.
  • Use git reset --hard <commit_SHA> to undo all changes since the <commit_SHA> specified. This changes your Git history, so BE CAREFUL using this command.
• Once you feel that you have completed a problem, please copy the code to an appropriately-labeled file within the HW3-final subdirectory. All code for Problem 1 should reside in a file called P1.py in HW3-final/, all code for Problem 2 should reside in a file called P2.py in HW3-final/, and so on.

Pull Request

• Once you have pushed your local development branch and commits to your remote repo, you should create a pull request (PR) to merge the changes in your development branch into your remote master branch.
  • Through the Github website, create a PR to merge your changes from HW3-dev into master.
  • Check that the files you created/changed are correct.
  • You will lose 2 points if a PR is not made.
  • Please make sure any files you want us to grade are in the HW3-final/ directory.
• DO NOT merge your PR into your master branch because we will be providing feedback on your homework through this PR. You will lose 3 points if you prematurely merge your PR and prevent us from properly providing feedback.
• Note: This PR process through Github is not typically the way you would work on a project solely owned by you. This workflow is more typical of how you would work on a group project or at a company in which someone should review your code before you can merge your code to the master branch. We want you to become accustomed to this type of workflow. It is a good idea to always use separate development branches. You should not commit straight to your master branch.
• Detailed Instructions:
  • From the Github website for your course repo, click on the "Pull Requests" tab
  • Create a new Pull Request
  • Select your homework branch as the branch to compare to master
  • Click "Create Pull Request" to create a pull request draft
  • Now click "Create Pull Request" again on the draft page.
  • You have now created a pull request. Please do NOT merge this into master until you have received feedback.

Homework Feedback:

• The teaching staff will provide feedback on your homework through Github pull request you make to merge your HWn-dev branch into your master branch. This will allow us to provide comments about certain lines of code you write.
• Once we are done providing comments and grading, you need to merge your HW3-dev branch into master. You will lose 3 points if you do not follow this instruction.

Homework rules:

• Assignments must be completed individually
• Collaboration is permitted as long as discussions are limited to high-level considerations.
  • For example, do not discuss implementation details
• Solutions must be your own!

Late Policy

Twenty points will be deducted per day for late homework. Homework will not be accepted that is more than 2 days late. For example, homework due on Thursday at 11:59 PM will no longer be accepted after Saturday at 11:59 PM.

Please contact me as soon as possible in the case of an unforeseen emergency or illness so we can figure out an approprate plan of action on a case by case basis.

Regrade Policy

DO NOT ask a TF any re-grading questions until AFTER the HW grades have been released on Canvas.

Reasonable re-grading requests will be accepted up to 48 hours after the final grades are submitted. All re-grade requests must be sent to cs107.sys.dev@gmail.com, with the subject line: HWn-Pms: Regrade request, <Your name>, where n is the assignment number, m is the problem, and s is the sub-problem (e.g. HW2-P2b). Please only send re-grade requests to this email. All other concerns should continue to be posted on Piazza.

Regrade requests will only be accepted for a single problem (do not request regrading for an entire homework set). Note that a requested regrade may cause your grade to go down since the entire problem will be reconsidered.

Piazza

The course will be using Piazza as a forum for discussion about course topics and questions from lecture or about assignments. Participation on Piazza by asking and answering questions will be considered in your participation grade. Students are encouraged to answer each other's questions. To facilitate this participation, the teaching staff will wait between 12 and 24 hours to respond to conceptual questions in the week that a homework assignment is assigned. In the week that a homework assignment is due and for questions relating to course policies or clarifications of assignment expectations, the teaching staff will try to respond more quickly.

A Note on Groups

You will be assigned a project group at the beginning of the semester. The group will have 3 or 4 members and we will try to assign it based on your timezone as well as your coding ability as determined by the course survey.