Merge branch 'main' of https://github.com/CMU-17-356/cmu-17-356.github.io

Author: Aditya Shrivastava

.github/workflows/ci.yml

@@ -16,7 +16,8 @@ jobs:
       - uses: actions/cache@v4
         with:
             key: ${{ github.ref }}
-            path: .cache
+            path: ~/.cache/pip
+      - run: sudo apt-get update && sudo apt-get install -y libxml2-dev libxslt-dev python3-dev
       - run: pip install mkdocs-material
       - run: pip install -r requirements.txt
       - run: mkdocs gh-deploy --force

docs/_data/schedule.yaml

@@ -372,19 +372,19 @@
     name: ''
   recitation:
     handout: ''
-    name: 'App Deployment'
+    name: 'Unit testing'
     quiz: ''
     slides: ''
 
 - date: Tue Feb 11
   homework:
     deadline: 'February 18, 2025'
     link: ''
-    name: 'HW4: DevOps'
+    name: 'HW4: Testing'
     numDays: 5
   lecture:
     link: ''
-    name: 'CloudOps'
+    name: 'Testing'
   reading:
     link: ''
     name: ''
@@ -420,7 +420,7 @@
     numDays: 0
   lecture:
     link: ''
-    name: 'Testing'
+    name: 'Test Automation and CI/CD'
   reading:
     link: ''
     name: ''
@@ -462,19 +462,19 @@
     name: ''
   recitation:
     handout: ''
-    name: 'Unit testing'
+    name: 'App Deployment'
     quiz: ''
     slides: ''
 
 - date: Tue Feb 18
   homework:
     deadline: 'February 25, 2025'
     link: ''
-    name: 'HW5: Testing'
+    name: 'HW5: DevOps'
     numDays: 5
   lecture:
     link: ''
-    name: 'Test Automation and CI/CD'
+    name: 'CloudOps'
   reading:
     link: ''
     name: ''

docs/_data/this_week.yaml

@@ -1,28 +1,28 @@
 last_homework:
   date: ""
-  deadline: "Tues Jan 28 @ 11:59pm"
+  deadline: "Tues Feb 4 @ 11:59pm"
   link: ""
-  name: "HW 2: MVP Creation"
+  name: "P0: Team Contracts"
   numDays: 1
 
 lectures:
-  - date: Tue Jan 28
+  - date: Tue Feb 4
     link: ""
-    name: "MVP Presentations"
-  - date: Thu Jan 30
+    name: "Coding as a Team Part 1"
+  - date: Thu Feb 6
     link: ""
-    name: "Team Forming and Norming"
+    name: "Coding as a Team Part 2"
 
 next_homework:
   date: ""
-  deadline: "Tue Feb 4 @ 11:59pm"
+  deadline: "Tue Feb 11 @ 11:59pm"
   link: ""
-  name: "P0: Team Contracts"
+  name: "HW3: Working with Github"
   numDays: 5
 
 recitation:
-  date: Fri Jan 31
+  date: Fri Feb 7
   handout: ""
-  name: "Node.js Apps"
+  name: "Github Basics"
   quiz: ""
   slides: ""

docs/assignments/hw3-25.md

@@ -0,0 +1,112 @@
+# Homework 3: Github basics
+
+## Learning goals
+
+- Get comfortable with Github if you aren't already
+- Think about secure development practices
+- Practice simple code review
+
+## Project context
+
+You and your team have access to a basic calculator app through Github classroom. Over the next three assignments, you'll (1) set up the repo and merge a few simple PRs (2) deploy the application and set up automated deployments and (3) write tests and create a continuous integration (CI) pipeline. **You should apply the development processes you learn here to your prototype product.**
+
+## Assignment instructions
+
+In this assignment, you'll set up your local development environment, securely configure your repo, make a PR, and review your teammates' PRs.
+
+You'll notice that a number of these steps address *security operations*. Why bother with a secure setup? Well, if you actually build a successful company, you (and your software!) become a target. If an attacker can gain write access to your source code, for example, they can insert backdoors that let them hold services ransom, steal user data, or even steal money. This opens you up to a world of legal and financial pain---but luckily, there are really simple things you can do that significantly raise the barrier for attackers. This assignment touches on several of them. 
+
+### 1. Configure Github with (non-SMS) 2FA
+
+Having a 2FA method makes it vastly harder for attackers to compromise your Github account and impersonate you.
+
+Follow [these instructions](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication) to set up two-factor authentication for your Github account. **This 2FA method must not be text message/SMS**. We reccomend [FIDO](https://fidoalliance.org/specs/u2f-specs-master/fido-u2f-overview.html) if possible, and [TOTP](https://datatracker.ietf.org/doc/html/rfc6238) as a backup option.
+
+#### Turn in instructions
+
+When you have done so, navigate to your Github profile; under Settings and Authentication, take a screenshot of the Preferred 2FA Method box that includes both the 2FA method and your username. Do not include anything else in the screenshot (this is possible due to the layout of the page).
+
+### 2. Configure Github with SSH
+
+Using SSH for Github authentication is both more secure and more convenient than using password authentication.
+
+Follow [these instructions](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh) to set up a new SSH key with Github if you haven't already. Specifically, you will:
+- [Generate a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent). Make sure to [use a passphrase](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/working-with-ssh-key-passphrases).
+- [Add the SSH key to your account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account).
+- [Test that everything worked](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/testing-your-ssh-connection).
+
+#### Turn in instructions
+
+Once you've done these things, navigate to the SSH and GPG page in your account settings, and take a screenshot that encompasses the name/hash identifier of the key of your SSH key and your username.
+
+### 2b for 10 point bonus: Configure commit signing
+
+To get ten bonus points, [configure commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Then, write and submit a couple sentences about why it's beneficial.
+
+#### Turn in instructions
+
+Submit a screenshot of your signed commits and your description.
+
+### 3. Clone the calculator repo onto your local machine
+
+When you navigate to the Code tabe, make sure you use the SSH tab, not the HTTPS tab. This will clone the repo using the SSH authentication flow.
+
+**There is no deliverable for this step.**
+
+### 4. Configure branch protection
+
+As it stands, anyone with access to your repo can push whatever garbage they want to the main branch. That's not good! It's important to make sure code that actually gets deployed has been thoroughly tested and reviewed (to catch everything from mistakes to intentional back doors!). In this assignment, you'll focus on code review; in a future assignment, you'll block merges to main until your code passes CI.
+
+To protect your main branch, navigate to the Settings tab in the calculator repo and click on Branches (on the lefthand side). You'll see two options: (1) Add branch ruleset and (2) Add classic branch protection rule. For now, you're just going to add a classic branch protection rule that protects main from direct, unreviewed commits: check the box to require a pull request before merging. Once you check this box, you will have the ability to require multiple PR approvals before merging is allowed. Require at least two.
+
+#### Turn in instructions
+
+Take a screenshot of your branch protection rules; we'll also check the repository directly. 
+
+### 5. Configure pull requests
+
+Your main history is much easier to track if all commits to main are uniform. Different teams have different preferences for this configuration, but in this class, we'll require [squash merging](https://learn.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash?view=azure-devops) for a clean history; this is a very common configuration.
+
+Navigate to the General settings. Under Pull requests, uncheck merge commits and rebase merging, leaving only squash merging checked. In the dropdown, select Pull request title and description. This means that only the PR title and description will show up in your main branch's commit history, and each feature branch will be squashed into a single commit. 
+
+#### Turn in instructions
+
+Take a screenshot of your repo's PR settings.
+
+### 6. Run the calculator app locally
+Follow the instructions in the **README** to set up and run the calculator on your machine. You can choose to deploy the app locally using either Docker or npm, depending on your preference. Ensure everything is working before proceeding with any modifications.
+
+**There is no deliverable for this step.**
+
+### 7. Add a piece of functionality to the calculator
+
+You will add a new piece of calculator functionality [*in a new branch*](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging). Then, you will [open a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request?tool=webui) (PR) so that your teammates can review and approve your changes. 
+
+Choose one of the following functionality: (Coordinate with your teammates to ensure no two members implement the same functionality.)
+1. **Backward Button**: Add a button that allows users to remove the last entered character in the calculator input field.
+2. **Custom Pop-up for Invalid Expressions**: Display a pop-up window when the user enters an invalid expression.
+3. **Brackets Support**: Add "(" and ")" buttons and ensure expressions with brackets are correctly handled.
+4. **Expression History Display**: Show a list of previously calculated expressions in the frontend. The list should reset when the browser is refreshed.
+5. **Backend Logging**: Log all expressions sent to the backend into a local file. The log should persist even after the browser is refreshed.
+
+Use your PR message to clearly describe the changes you've made to the calculator app.
+
+#### Turn in instructions
+
+Please provide us a link to your PR.
+
+### 8. Review at least two PRs
+
+Following the best practices we discussed in class, leave two reviews on your teammates' PRs. If there issues, continue to discuss in the comments until you're satisfied with the changes and able to approve the pull requests.
+
+#### Turn in instructions
+
+Please provide two or more links to your reviews. 
+
+### 9. Merge your reviewed PR
+
+Finally, once your PR has been approved, [merge it](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request).
+
+#### Turn in instructions
+
+Please provide a link to your merged commit. 

docs/project/p1.md

@@ -0,0 +1,123 @@
+# Project 1: Project Specification
+
+## Learning Goals
+
+- Practice hypothesis testing and the MVP loop
+- Refine your product idea
+
+## Project Context
+
+You and your team will be spending the rest of the semester building a product prototype for your startup. 
+This assignment is intended to help you build something viable (that I hope will become the basis for a real company someday).
+
+**Please read the assignment in its entirety before starting**. As you move through parts 1 and 2 and refine your ideas/pivot, keep in mind the legal/regulatory/technical questions from part 3. In other words, *try to make sure you're working on something legal and feasible even as your idea changes*. 
+
+## Deliverables
+
+These deliverables should be somewhat familiar from homeworks one and two. Now, you're doing them "for real," trying to hone in on the product you and your group will be producing for the rest of the semester.
+
+### 1. Initial value proposition/product description
+
+#### Turn-in instructions
+
+Please answer the following questions:
+1. What is the big idea of your startup? What problem are you solving? What is your solution? What makes your solution special and distinguishes it from the competition? (1-2 paragraphs)
+2. What is/are the value proposition(s) for your product? (1-2 sentences)
+
+### 2. Viability analysis: do people want it?
+
+In these exercises, you'll collect some initial viability data, and make
+a plan for collecting more as you build out your prototype. 
+
+#### 2a. Measure/demonstrate that people want your product *before building anything*
+
+Recall the unbiased discovery you did during HW1. You're going to collect more data this time, from a broad range of members of your target demographic. If your target demographic is gymgoers, for example, you should talk to at least a few non-student gymgoers. This will help you determine who your target demographic actually is (and thus refine your value prop).
+
+You will have **twenty or more** discovery conversations across your group, **with each team member conducting at least two conversations**. These conversations should give you valuable data about the problem you're trying to solve; if you haven't been forced to refine your idea, at least slightly, over the course of these conversations, you are likely doing something wrong.
+
+##### Turn-in instructions
+
+Please turn in:
+1. Your notes, demonstrating that every group member participated in at least two interviews.
+2. The five most useful questions you asked. (1 paragraph)
+3. The five most useful pieces of concrete data you collected. (1 paragraph)
+4. An updated version of your value proposition/product description (question 1), informed by your discovery. Describe what changed and why. (3+ paragraphs)
+
+#### 2b. Measure/demonstrate that people want your product after building something *minimal*
+
+In class, we've discussed several ways to get feedback from users without building an entire application:
+- Concierge MVPs
+- Smokescreen MVPs
+- Paper prototypes
+- Kickstarter-style campaigns
+- ...etc.
+
+Think about which of these makes sense for your startup.
+
+##### Turn in instructions (1-2 pages)
+
+Choose at least one data-gathering approach for your startup and describe:
+1. Why you chose it.
+2. What you built (with a link or pictures if relevant; for a smokescreen MVP, for example, please link to the MVP webpage or demo).
+3. How you gathered feedback (e.g., for your smokescreen MVP, where did you circulate the link?). 
+4. What you learned from the feedback (e.g., did a thousand people view your webpage, while only one signed up for the list? What does that tell you?)
+5. An updated version of your value proposition/product description (question 1), informed by your data gathering. Describe what changed and why. 
+
+#### 2c. Prototype plan: how little can you build and still get valuable feedback?
+
+As you're refining your idea, it's important to figure out what you're going to build (and possibly start building!). For this piece of the milestone, you'll sketch out (a) your first two MVP milestones and (b) how you will get feedback on these milestones from real users.
+
+#### Milestone one (1-2 pages) turn in instructions
+
+1. Describe, at a high level, the feature you are building.
+2. Why is it the right feature to build?
+3. How will you use this feature to collect data about your what your users want?
+4. Describe what you will build in a reasonably low-level technical detail (e.g., what frameworks will you use, what API endpoints will you expose, what UI components will you create, etc).
+
+#### Milestone two (1-2 pages) turn in instructions
+
+1. Describe, at a high level, the feature you are building.
+2. Why is it the right feature to build?
+3. How will you use this feature to collect data about your what your users want?
+4. Describe what you will build in a reasonably low-level technical detail (e.g., what frameworks will you use, what API endpoints will you expose, what UI components will you create, etc).
+
+### 3. Viability analysis: are there reasons not to build it? Can you build it?
+
+Answering these questions will help you avoid attempting the impossible; please upload your answers for each.
+
+#### 3a. Legal risk turn in instructions (1+ paragraph)
+
+Describe the legal risks associated with your product. *The majority of the work of this question should be research.*
+
+#### 3b. Regulatory risk turn in instructions (1+ paragraph)
+
+Describe the regulatory risks associated with your product. *The majority of the work of this question should be research.*
+
+#### 3c. Competitor risk turn in instructions (3+ paragraph)
+
+Describe your product's competitive landscape, including its three closest competitors. What do these products do? How is your product different?
+
+#### 3d. Technical risk turn in instructions (3+ paragraph)
+
+**Desribe, in a relatively fine-grained level of technical detail, what you are planning to build.**
+What tools/frameworks/libraries are you planning to use for:
+- The frontend
+- The infrastructure
+- The database
+- Other technical core features. For example, if your product uses computer vision, what library are you planning to use?
+
+**Explain why your group has the background to build these features**. For example, if you're building devtools for ML data processing, please outline your experience with ML and data processing. 
+
+#### 3e. This-is-a-semester-long-course risk turn in instructions (1+ paragraph)
+
+**Please justify why it is possible to build a prototype product over the course of this semester-long class.** As one anti-example, fabricating new chips for ML workloads is certainly an exciting thing to do, but it's also something you can't do over the next couple months. Avoid such endeavors.
+
+### 4. Viability analysis: could it make money?
+
+#### Turn-in instructions
+
+Please turn in answers to the following questions:
+1. What evidence do you have that people are willing to pay for your product? (2 paragraphs)
+2. What is your monetization plan? (1+ paragraph)
+3. What is your projected revenue across the first 10 users of your application? 50? One thousand? (1-2 paragraphs)
+4. What is the value of similar competitors? (1-3 paragraphs)

requirements.txt

@@ -63,7 +63,7 @@ parso==0.8.4
 pathspec==0.12.1
 pexpect==4.9.0
 pickleshare==0.7.5
-pipreqs==0.5.0
+pipreqs==0.4.13
 platformdirs==4.2.2
 prompt_toolkit==3.0.47
 Protego==0.3.1