+ Milestone 5
+
+
+Tuesday, December 11th, 09:59 PM
+
+With the development in full swing, this milestone aims to check the integration of a few modules.
+API tunning
+As you develop the project, you learn more about the structure, the modules, and so on. The initial API might not be the best, and you might want to change it. You can leave your API draft untouched, as long as it complies with the contract conditions. For the rest of this document, it the latest version of your API will be referred as modified.
+Features and Integration
+Developing individual features is straightforward. Integrating them into a cohesive piece of code is the challenge.
+For this item, develop features of different modules, and perform integration tests on github actions.
+You can merge into dev when the feature pass your tests, but Do not delete the branches used to develop new features until the teaching staff review them.
+Remember to commit frequently. Tests should be commited and pushed before any code is written.
+
+- Write the integration tests according to your
modified API.
+- Implement at least two consecutive modules, including the unit tests, code and documentation. If you have already written the modules, you still have to push the tests first.
+- The integration of two modules is correct when all the integration tests pass.
+
+Note: You should commit multiple times to your local repository and clean the local history if needed. Push only when you pass the unit tests.
+Steps to complete
+
+- In the
main branch and within your docs sub-directory, create a file called milestone4. The type of file is up to you and your group. Two acceptable choices are markdown (milestone4.md) or a Jupyter notebook (milestone4.ipynb).
+- Your
milestone4 document submission should be in the following format:
+
+teamXX/
+├── docs
+│ └── milestone4
+├── LICENSE
+├── README.md
+└── ...
+
+- Describe the software organization and licencing in
milestone4.
+- Create branch
dev.
+- Create the branch
featurename to implement your module. Replace "featurename" with the name of the module you want to implement.
+- In that branch, write the tests for the module you want to implement. You should commit them before the writing/pushing any other code.
+- Write the code for the module you wrote the tests for.
+- Every test for the modules should pass.
+- The code coverage must be at least 90%.
+- Merge the branch into
dev.
+- (Optional) You can implement another feature, following steps 5-10. You are encouraged to develop the main modules as soon as possible, to focus on the integration later on.
+
+Final Deliverables
+
+- The
docs/ directory should include a document called milestone4 (the
+ extension is up to you, but .md or .ipynb are recommended.
+- Proper licensing of your project.
+- Tests and implementation for your module(s).
+
+Grading breakdown
+
+
+
+
+| Points |
+Task |
+
+
+
+
+| 4 |
+Software Organization |
+
+
+| 4 |
+License |
+
+
+| 15 |
+Implementation |
+
+
+| 15 |
+(optional) Additional implementation |
+
+
+| 23(38) |
+Total |
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/docs/tipuesearch_content.js b/docs/tipuesearch_content.js
index c766c0a..0339d3a 100644
--- a/docs/tipuesearch_content.js
+++ b/docs/tipuesearch_content.js
@@ -1 +1 @@
-var tipuesearch = {"pages":[{"title":"CS107/AC207 Project","text":"Project Overview Goal You will develop a software library for a client, the teaching staff. The development of this library will leverage modern software development practices covered in the course. By the end of the semester, the client should be able to easily install and run your package. Topic The project topic is spectral analysis , which consists of the analysis of data obtained from publicly available sources currently used by professional astronomers to perform state-of-the-art research. Moreover, spectral data appears in many fields of science and engineering, and you are likely to encounter it in your professional careers. Your final project is to write a Python library. Your library is not required to have every module implemented; that would simply be too much for a single semester. However, your library should meet the basic project expectations outlined in the Software Requirements Specification (SRS). Project Milestones The following weight table is used for individual milestones of the project. The individual milestones make up the final project grade listed under the Grading section in the syllabus. Additional milestones will be included in the near future. The due date for the final milestone is December 14th 2022, 09:59 PM. Milestone Due Total Points Milestone 1 Thu, November 2nd, 09:59 PM 1 Milestone 2 Thu, November 9th, 09:59 PM 1 Milestone 3 Tue, November 14th, 09:59 PM 21 Milestone 4 Tue, November 28th, 09:59 PM 23 Total 46 Groups You will work in groups of 4-5 students. You are free to choose your project partners but groups sizes must consist of the number of students mentioned before. Some members of the group will be stronger than others. It is expected that you work together and help each other as needed. This is an opportunity for less experienced coders to improve their skills by working with more experienced coders. Every person must contribute. Expectations This project encompasses several mandatory requirements, detailed under basic expectations and within Annex A of the Contract. Furthermore, the project includes supplementary elements, specified under additional expectations and delineated in Annex B of the Contract. Basic Expectations Python library that can be used for astronomical spectral analysis. The library must comply with the API described the Contract. The client should be able to easily install the library, run the tests, access the documentation, and use the library for their application. Documentation for every subsystem in the project must be provided. Link to the docs from the README.md in each folder. The top level README.md should contain an overview, links to other docs, and an installation guide which will help us install and test your system. The project must utilize a proper packaging system for distribution and installation of the library. The project must ship with a test suite. Documentation on how to run the tests is mandatory. Additional Expectations In addition to the basic requirements of the library, you must also extend your package with at least two additional modules. Cross-Matching Machine Learning Interactive Visualization Spectral Feature Extraction You are more than welcome to pitch your own idea, which must be approved by the Teaching Staff. Broader Impact You must write a broader impact statement for your library. The broader impact should consider the accessibility of your software library to different groups of people. This statement should be around 250 words (approximately 1/2 page). It can be placed in the README.md of your library. Things to consider when writing this statement are: How will you make your library accessible to different groups? What process will contributions to your library need to go through? How will you ensure that this process is fair and welcoming to all groups?","tags":"pages","url":"pages/project.html"},{"title":"Resources","text":"Books No book is required. But we highly recommend two books for this course. Fluent Python: Clear, Concise, and Effective Programming, by Luciano Ramalho. Publisher: O'Reilly Media. 2015. Designing Data Intensive Applications, by http://dataintensive.net/ , The Big Ideas Behind Reliable, Scalable, and Maintainable Systems by Martin Kleppmann. Publisher: O'Reilly Media 2014 Other useful books The Practice of Programming by Brian W. Kernighan and Rob Pike, Addison-Wesley, 1999. Skiena: The Algorithm Design Manual Abelson, Sussmann and Sussmann: SICP and python based online version based on it: http://composingprograms.com/ High Performance Python: By Micha Gorelick, Ian Ozsvald. Oreilly Media 2014. Evaluating Derivatives: Principles and Techniques of Algorithmic Differentiation by Andreas Griewank Papers and other readings Python pep8 An opinionated guide to python style Git Recommended: Git from the bottom up Recommended: Git Book GitHub Videos and Training GitHub Interactive Tutorial Git - the simple guide Git Reference Git Cheat Sheet Git Immersion Tutorial Git Atlassian Tutorial Python python Rich overview of Python 3 language features (recommended to work through) Scientific visualization with Python and Matplotlib C/C++ Fall 2021 C/C++ primer material C Tutorial C++ Tutorial C++ Cheat Sheet C++ Reference Vim Spend 30 minutes to complete the vimtutor . After you have installed vim , execute the following command in your command line: vimtutor Vim Cheat Sheet Vimcasts Recommended book Bash Command Line Reference Cheat Sheet Bash scripting Cheat Sheet Unix-Related Basic Computing Tools Windows Users Using Linux Subsystem on Windows 10 PuTTY SSH client for Windows Ubuntu Docker Image You can get an Ubuntu based Docker container with docker pull iacs/cs107_ubuntu The container is hosted here . The Dockerfile and run_cs107_docker.sh launch script can be found in the class repository .","tags":"Resources","url":"pages/resources.html"},{"title":"Schedule","text":"","tags":"pages","url":"pages/schedule.html"},{"title":"Schedule","text":"All due events with a given date are due on 09:59pm that day . Wk Tuesday Thursday Labs Events 1(35) Lecture 1: 2023-09-05 Class introduction/organization History of Bell Labs, Unix and Linux Command line introduction Lecture 2: 2023-09-07 More command line Pipes Regular expressions File attributes 2(36) Lecture 3: 2023-09-12 Command line customization I/O redirection Environment variables Shell scripting Process management Lecture 4: 2023-09-14 Version control systems (VCS) Centralized and distributed models Intro to Git PP01: (2023-09-12) Setup private class repository, tmate . 3(37) Lecture 5: 2023-09-19 Version control systems (VCS) Managing repositories Remote repositories Branching Lecture 6: 2023-09-21 Python basics Objects and Functions Environments Closures PP02: (2023-09-18) Bash scripting, Git workflow. Note: PP01 deadline (2023-09-22) 4(38) Lecture 7: 2023-09-26 OOP in Python Classes Inheritance Polymorphism Lecture 8: 2023-09-28 Python data model Dunder methods Software licenses PP03: (2023-09-25) Git local branches, merge conflics and merge tool. Note: HW1 deadline (2023-09-27) PP02 deadline (2023-09-29) 5(39) Lecture 9: 2023-10-03 Classes and methods Modules and packages Python Package Index Lecture 10: 2023-10-05 Databases SQL SQLite PP04: (2023-10-02) Python closure, fully connected neural networks. PP03 deadline (2023-10-06) 6(40) Lecture 11: 2023-10-10 Databases: OLAP & OLTP SQL: Joins Lecture 12: 2023-10-12 SQL Joins Pipelines Case Study PP05: (2023-10-10) SQL and SQLite in Python. HW2 deadline (2023-10-13) PP04 deadline (2023-10-13) 7(40) Lecture 13: 2023-10-17 Pipelines Software systems Documentation Lecture 14: 2023-10-19 Testing PP06: (2023-10-16) SQL and pipelines. PP05 deadline (2023-10-20) 8(40) Lecture 15: 2023-10-24 Testing revisited Exeptions Test coverage Lecture 16: 2023-10-26 Continuous integration PP07: (2023-10-23) Documentation and testing Quiz #2 deadline (2023-10-25) HW3 deadline (2023-10-27) PP06 deadline (2023-10-27) 9(40) Lecture 17: 2023-10-31 Containers Virtual environments Docker Lecture 18: 2023-11-02 Data structures Linked lists Iterators PP08: (2023-10-30) Package deployment PP07 deadline (2023-11-03) 10(40) Lecture 19: 2023-11-07 Binary search trees Tree traversal Priority queues Lecture 20: 2023-11-09 Heaps PP09: (2023-11-06) BST, Docker images HW4 deadline (2023-11-10) PP08 deadline (2023-11-10) 11(40) Lecture 21: 2023-11-14 Generators Coroutines Lecture 22: 2023-11-16 Python internals Memory PP10: (2023-11-13) TBD PP09 deadline (2023-11-17) 12(40) Lecture 23: 2023-11-21 CATCH UP lecture Thanksgiving break: 2023-11-23 No PP11 PP10 deadline (2023-11-17) 11(40) Lecture 24: 2023-11-28 Performance Lecture 25: 2023-11-30 Project work PP12: (2023-11-27) TBD Quiz #3 deadline (2023-11-30) 11(40) No lecture: 2023-12-05 Work on the project Work on other projects Rest and relax Reading period: 2023-12-07 PP12 deadline (2023-12-01) 11(40) Final exam period: 2023-12-12 Final exam period: 2023-12-14","tags":"pages","url":"pages/schedule_static.html"},{"title":"Syllabus","text":"Course Objective The primary goal of this course is to teach you how to develop effective software for scientific applications. In order to achieve this goal, there are several non-negotiable topics that must be included in the course. We will be concerned with two primary thrusts: System and Software Engineering and Language . Moreover, we aim to provide you with a suite of modern software development techniques and workflows. Learning Objective After successful completion of this course, you will be able to: Use Python, including its advanced features to write scientific programs. Have a basic idea how the Python interpreter works. Understand what features of Python make up its language execution model and how these features impact the code you write: e.g. how modularity, abstraction, and encapsulation can be used to solve problems. Write programs with good software engineering practices. These practices include: working on remote machines, version control, continuous integration, documentation and testing. Utilize data management techniques to store data, starting from a good understanding of data structures to databases. Combine these techniques together to write large pieces of software working in a team. Develop pipelines to integrate data aquisition and processing. Evaluate and test software as part of the development process. Be able to contribute on both the science and software engineering sides of things. Prerequisites You should have some basic familiarity with programming (functions, variables, constants, differences between integer and floating point, etc.) at the level of CS50. Some comfort with a tool to edit text files is beneficial. Any text editor or IDE will suit this purpose. The student should have passed a basic calculus class. The lectures will review the necessary fundamentals required to succeed with the class project. Besides this, you should have interest or investment in scientific computing. You can download Homework 0 for self-assessment here (not graded). You do not need to be able to solve all problems in order to take this class. Jupyter Notebooks Jupyter notebooks are great for code prototyping and learning how to use new features and APIs. However, they are not suitable for large software development projects! One reason for this is because code development in Jupyter notebooks is a nonlinear development process and there is presently no good solution for version control of Jupyter notebooks. A second reason is the question of efficient source editing. A helpful tool to convert (back and forth) Jupyter notebooks to pure python code is Jupytext . Homework assignments and lecture exercises turned in as Jupyter notebooks will not be graded. Textbooks There is no required course textbook. However, the course content will draw from various sources. We will cite the source when appropriate. Please consult the resources page for recommended textbooks and additional helpful material. Course Format The delivery of course content will occur via two weekly lectures as well as weekly pair-programming sections. Attending these sessions is mandatory . Lectures will consist of considerable interaction and discussion and will be greatly enhanced by student participation. The course contains the following main components: Lectures: Deliver the main content of the class. Attendance is mandatory. Quizzes: Graded in-class quizzes intended to assess the learning progress. Pair-programming: Pair-programming (PP) sections offer practice on topics addressed in class and help assess the skills to program in a collaborative environment. Attendance is mandatory. Homeworks: Homework assignments deepen the lecture material and include coding exercises. Exercises may be of theoretical or practical nature. Projects: The class is accompanied by a project (teams of 4-5 students) to practice the methods learned in class on a real Python application. The project topic is given by the teaching staff. The main programming language taught throughout the course is Python. Grading The following weight table is used for individual components of the class. The class does not have standard midterm or final exams. Total Weight Homework (5 Homeworks) 35% Project 35% Quizzes (3 Quizzes) 15% Pair-programming (11 sections) 15% Homework There are 5 homework assignments where each contributes equally to the final grade. The homework is focused on the topics discussed in class and involves programming and theoretical work. The teaching staff is determined to return solutions and graded assignments with feedback after the due date. It is your responsibility to check the consistency between your graded work and the assignment solution. You have the option to address possible inconsistencies in office hours or request a regrading for the assignment (see the homework grading inconsistencies section below). Homework will be released on the CS107/AC207 class repository . Push notifications for that repository will be distributed through the class mailing list . 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 Submission Homework must be submitted via commits in your private git repository hosted in the CS107 organization at https://code.harvard.edu/CS107 . Grading and feedback for homework is done through the Gradescope platform which is connected to the class' Canvas site . Your homework solutions must therefore be zipped and uploaded in the Gradescope section of the class canvas. See the homework workflow tutorial for more details. The homework due date is indicated on the problem sheet and displayed in the schedule as well as shown on Canvas and Gradescope. Homework submissions will be graded on: Correctness: your code must run and must produce the correct result. We are not debugging issues when grading submissions. Presentation: presentation means structure and readability. We expect you to write high-quality, readable and tested code. A quality code is well commented in places where it is not straight forward to deduce the logic from code itself (from the reviewers perspective). We expect you to think about aspects such as modularity, reusability, code duplication and error handling when you design and write code. Presentation of results also means that unnecessary or superfluous files like editor backup files or other unrelated data should not be included in the submission commits (use .gitignore for this purpose). See the following tutorials to help you get started with homework submissions: How to setup your private class repository (onetime setup) Homework workflow Homework Late Days Homework submissions are accepted before the deadline of the assignment is due. You have three late days at your disposal that can be consumed for late submissions and two consecutive late days can be used at most for any of the homework assignments. Please note that any commits on your homework branch pushed after the deadline has passed are not considered for grading by default. If you wish that we consider a late commit for grading, please contact the teaching staff at cs107-staff@g.harvard.edu with appropriate explanation. This will count towards your late day budget. It is your responsibility to plan your work ahead and commit on time. If you have consumed all your late days and you have another late submission, it is in your benefit to still commit the work. We assume the Harvard Honor Code for all late submissions in case solutions are already posted. If you have a verifiable medical condition or other special circumstances that interfere with your coursework please let us know via cs107-staff@g.harvard.edu as soon as possible. Homework Grading Errors If you believe there is an error in your assignment grading, you can submit a regrade request through the Gradescope platform . Note: The entire assignment will be regraded. This may cause your total grade go up or down . An assignment can only be regraded once . Regrade requests are due within 2 days after the release of the grades . Project Please see the project section for more details. Quizzes There are 4 quizzes out of class which are graded and intended to assess the learning progress. Each quiz addresses topics from the lecture material . Quizzes are open book/ www and include multiple choice questions with at most back of the envelope calculations. Quizzes contain around 15-20 questions and take 30 minutes. They are accessible on canvas within a 24 hour time window from 8pm. Note: if a quiz takes 30 minutes and you start the quiz on 8:50pm, you will have only 10 minutes to work on the quiz. Please see the class schedule as well. Pair-Programming Sections Pair-Programming will form an essential part of the course. Pair-programming will take place in mandatory pair-programming sections led by members of the teaching staff. You are required to sign-up for your preferred pair-programming section at the beginning of the semester. You are expected to attend your chosen section during the semester. Should you not be able to attend one of your sections, please coordinate with your section TF to attend another section this week in order to obtain the attendance credit. In CS107/AC207 we are focusing on command line tools for the development of software projects in computational science. It is important that you get familiar with a small selection of such tools and integrate them in your development process. The pair-programming sections aim at combining some of these tools together to provide you with hands-on experience while developing software. The key is the \"pair\" in pair-programming. The exchange of knowledge between team mates in these pair-programming sections is essential for learning said tools or learning something new from your peers. Pair-programming Submissions Pair-programming exercise solutions must be submitted in your private git repository hosted in the CS107 organization at https://code.harvard.edu/CS107 . Only commits made on or before the due date will be considered for grading . The deadline for submission is usually one week after the last section for the exercise. Given this extra time for completion, late days do not apply to pair-programming exercises . The submission due date is indicated on the problem sheet and displayed in the schedule . As you are working in groups of 3-4 students for the lab exercises, the solution files you come up with in the group are submitted by each group member individually in her/his own private Git repository. Pair-programming submissions will be graded based on the following criteria: Attendance: your attendance will be recorded by the TF who leads the section. Joining the section at the beginning and then leaving 10-15 minutes later will not reward attendance credit. If you need to leave because of another appointment then it is expected that you communicate beforehand and coordinate with your TF. Please see the attendance policy section below as well. Your pair-programming session is determined at the beginning of the class by choosing lab sections in my.harvard . You can select your preferences depending on your schedule. Once determined, you can lookup your session details in the https://code.harvard.edu/CS107/main/blob/master/lab_groups.xls sheet. Completion: pair-programming submissions should reveal effort that the student attempted to solve the tasks. If you experience difficulties in a particular problem and you are not able to complete the task, please indicate the issues you had in your code using comments; the teaching staff will take that reasoning into account. Handing in an empty skeleton (same as hand-out) does not meet the expected standard and will not award credit for the submission. See the following tutorial to help you get started with pair-programming submissions: Pair-programming workflow Office Hours The teaching staff holds weekly office hours. Office hour times and locations are listed on the class main page. Office hours offer an opportunity to review course materials and receive additional guidance on your homework. Please see the following file in the class git repository for the details: https://code.harvard.edu/CS107/main/blob/master/office_hours.xls Attendance Policy Attendance at lectures and pair-programming sections is mandatory as they are core parts of the class. Pair-programming sections (labs) will be held on weekdays that we determine at the beginning of the class according to a best fit of the students' individual schedules for the term. You are required to attend the labs on the assigned day. Rescheduling of a lab to a different day due to an unforeseeable event must be coordinated with the responsible TF by sending an email to cs107-staff@g.harvard.edu . To be excused from a lecture or a lab, we ask you to follow the Harvard Honor Code and send an email to cs107-staff@g.harvard.edu at least one day before the lecture or lab. Lecture recordings are available only when students are excused for a lecture. Collaboration Policy You are welcome to discuss the course material and homework with others in order to better understand it, but the work you turn in must be your own (with exception of the project where collaborative work is permitted). Any work submitted as your own without properly citing the original author(s), is considered plagiarism. Failure to follow the academic integrity and dishonesty guidelines outlined in the Harvard Student Handbook will have an adverse effect on your final grade. This includes the removal of copyright notices in code. You may not submit the same or similar work to this course that you have submitted or will submit to another without permission. The teaching staff may use tools to compute correlations between submitted work. Use of AI Models Purpose of Policy: This policy outlines the acceptable use of AI models, including but not limited to ChatGPT, in completing assignments for this course. Policy Guidelines: Original Work: Students are expected to complete assignments using their original thoughts and interpretations. AI models can be used to help understand concepts, generate ideas, or learn about different perspectives, but they should not write or complete assignments for students. Collaboration with AI: Students may use AI models for brainstorming or generating preliminary ideas, but the final work submitted must be substantially their own. Students should be able to explain their reasoning, logic, and conclusions without relying on the model's output. Restrictions for Specific Assignments: There may be specific assignments (e.g. quiz part of the midterms) or parts of the course where the use of AI models is entirely prohibited. These restrictions will be clearly stated in the assignment guidelines. Ethical Considerations: Students are encouraged to approach the use of AI with ethical considerations in mind, including issues related to privacy, bias, and authenticity. Consequences for Non-Compliance: Failure to adhere to this policy may result in academic penalties as outlined in the course's academic integrity policy. Questions and Clarifications: If students have questions about the appropriate use of AI models in an assignment, they should consult the course instructor or teaching assistants before proceeding. Please refer to the University's policy for further information. Accessibility If you have a documented disability (physical or cognitive) that may impair your ability to complete assignments or otherwise participate in the course and satisfy course criteria, please contact the teaching staff or directly the Accessible Education Office to receive an AEO letter that will authorize us to help you with corresponding accommodations. Diversity Statement All participants in this class are expected to foster empathy and respect towards each other. This includes instructors, teaching staff or students. The motivation to take this course shall be to experience the joy of learning in an environment that allows for a diversity of thoughts, perspectives and experiences and honors your identity including race, gender, class, sexuality, religion, ability, etc. Any constructive feedback for improving the class environment is welcome and I encourage you to reach out to the instructor or teaching staff with any concerns you may have. If you prefer to speak with someone outside of the course, you may find helpful resources at the Harvard Office of Diversity and Inclusion .","tags":"pages","url":"pages/syllabus.html"},{"title":"Tutorials","text":"How to Setup your Private Class Repository Steps to Setup Your Private Class Repository Add an SSH Key to Your Account Homework Workflow Example Homework Workflow Step 1: Branch Off Step 2: Solving the Homework Step 3: Create a Pull Request Creating a Web Pull Request Step 4: Submit on Gradescope Pair-programming Workflow Protocol How to launch tmate Recommended Workflow How to Setup your Private Class Repository All of your work in CS107/AC207 will be committed in your private class git repository hosted in the CS107 organization at https://code.harvard.edu/CS107 . (The class project will be hosted in another repository in the same organization, see Milestone 1 for this separate task.) This tutorial walks you through the steps to create your private class repository. If you have already created git repositories on GitHub, then there is nothing new to learn in this tutorial and you should be familiar with the process already. A note on https://code.harvard.edu/ : this is an instance of a GitHub Enterprise edition hosted by Harvard University. The user interface is identical to the public GitHub site. The main difference is that https://code.harvard.edu/ is owned by Harvard University , whereas GitHub belongs to Microsoft which gives rise to security concerns regarding data belonging to classes held at Harvard University. Steps to Setup Your Private Class Repository Obtain your Harvard NetID Send an email to cs107-staff@g.harvard.edu (using your .harvard.edu email) to request access to the CS107 organization . Include your NetID from step 1 in the body of the email and choose an appropriate subject line. Once added to the organization, navigate to https://code.harvard.edu/CS107 (login if necessary) and click the green \"New\" button to add a new repository. Your repository must be named after your NetID . You can add an optional description if you like. Make sure the private radio button is checked and click \"Create repository\". You do not need to check any other options. This is all you have to do for now. In the first homework we will focus on how to setup your new repository such that you can work with it from your laptop (you can skip the landing page after you have created the repository). When you navigate back to https://code.harvard.edu/CS107 you should see something similar to this: The blurred repository is your private class repository that was the focus of this tutorial. The main repository is the main CS107/AC207 class repository which is used to distribute all of the class material during the semester. Any updates to this repository will be broadcast via email message such that you will not miss out on new material. In the first homework we will set this repository as an upstream such that you can conveniently unpack class material into your private repository. Note: private repositories are only visible to you within the organization. Please do not create other repositories in the https://code.harvard.edu/CS107 organization. You have your own user account on https://code.harvard.edu/ just like you have on GitHub or other providers. Your user account requires your Harvard login credentials and is a good alternative to hosts like GitHub. Feel free to create as many repositories in your user account as you like. Add an SSH Key to Your Account In order to access content on https://code.harvard.edu using Git you need to setup an SSH key. Check if you already have the file ~/.ssh/id_rsa.pub (assuming RSA). If you do not have such a file you can create one with ssh-keygen -t rsa -b 4096 Choose the default location by just hitting enter. You may enter a password for the key or just hit enter to go without password. If go with password you will have to enter it every time you use the key. To upload the public key to your Harvard GitHub account , click on your icon in the top right corner on your https://code.harvard.edu page, then click on \"Settings\" and then \"SSH and GPG keys\" in the left panel. Alternatively use this link https://code.harvard.edu/settings/keys . Click on the green \"New SSH key\" button in the top right corner and give your new key a title (e.g. the name of your laptop). In the key field paste the contents of your public key found in ~/.ssh/id_rsa.pub . Use for example cat ~/.ssh/id_rsa.pub and copy paste the output into the \"Key\" field on your GitHub page. You are now able to access any repositories on https://code.harvard.edu with corresponding permissions. Never share your private key ~/.ssh/id_rsa with anybody. Note: do not create a key in the class Docker container since the key will be lost when you exit the container. For security reasons, sensitive keys like this should not be put in containers. Homework Workflow The following are the basic rules we apply for homework submissions: Naming convention for homework directories: your private repository should contain one homework directory on the repository root with hwX sub-directories for each homework assignment. The X in hwX is to be replaced with the assignment number. For example hw1 , hw2 and so on. Which files will be considered for grading: within the sub-directory hwX , place the assignment files that you want us to grade in a directory called submission . We will only grade data in these directories . Pull request (PR): your homework assignments must be completed on git branches called hwX , where X is again to be substituted with the assignment number. Your homework X submission requires an open pull request to merge the hwX branch into your main (or deprecated master ) branch for full points (both branches are inside your private class repository in the CS107 organization ). Some implications of this: Solving homework on the main or master branch is always wrong. For each homework submission you need to issue one open PR. Merging an open PR before the teaching staff has reviewed and graded your work will make the PR disappear . Only files inside submission in PR X will contribute to your hwX grade (see next item). Gradescope: your homework will be graded on the Gradescope platform that has been setup and linked to the class canvas page. The platform does currently not support submission directly via your Git repository. You therefore have to create a zip archive of your submission directory created in step 2 above and upload the archive on Gradescope . It is important that you zip-up the directory and not individual files inside. You can use the command zip -r submission.zip submission/ , where the -r option means add files recursively , submission.zip is the name of zip archive and submission is your homework submission directory from step 2 containing your solution. This assumes you are in homework/hwX inside your Git repository. Points will be lost if any of these requirements are violated . The teaching staff will review the open PR for each homework and grade your work accordingly. Grades will be released on canvas and feedback is provided through the Gradescope platform. Once you have received the grade and feedback, your open PR for homework X can be merged into your main or master branch if there are no more pending issues. After the PR is closed, you may delete the hwX branch in your repository. This concludes a homework submission. Example Homework Workflow This example is intended to help you internalize the three basic rules described above. Each homework awards 10 points by performing these steps correctly. Note: Specific instructions provided in each homework assignment may override the following basic approach. Suppose we want to work on homework assignment 3, which consists of 4 problems. Step 1: Branch Off The ease of branching is the main strength of git . Branches allow you to be destructive without affecting production code or data. The reason we solve homeworks on individual branches is to help you develop a feel for this protection and to materialize the required steps to create branches. Branches will provide you true comfort when working on real projects outside of this class. Make sure your master or main branch is in the state you want your new branch to be based on. If you need to synchronize with your default remote branch you can type git pull The next step consists of creating and switching to a new branch that is based off the current branch. For this you can use git checkout -b hw3 which is how you did it before git 2.23.0 . Since the checkout command is ambiguous , the preferred way for more recent versions of git is git switch -c hw3 You are now on a new branch called hw3 as required. You will need to issue a pull request into main or master from this branch such that your homework will be graded. You can create the PR now (see below) or once you are done with solving hw3 , it does not matter to git . (Pull requests are not something designed by git itself, but rather by platforms like GitHub or GitLab.) Note: you will lose 5 points if you are not solving your hwX (in this example it is hw3 ) on a branch named hwX . You are of course free to create additional branches besides hwX if suitable. Step 2: Solving the Homework The files the teaching staff will consider for grading have to be located in the directory homework/hw3/submission . You are free to put other files below homework/hw3 that might be useful when you revisit your work sometime later. The problem sheet might be one of those files. Class handouts are distributed in the main class repository . You can manually create these directories and copy the files you want into your hw3 directory using, for example: mkdir -p homework/hw3/submission cp