Update master references to main

.github/workflows/jekyll.yml

@@ -16,7 +16,7 @@ jobs:
           retention-days: 2
 
   deploy:
-    if: ${{ github.ref == 'refs/heads/master' }}
+    if: ${{ github.ref == 'refs/heads/main' }}
     needs: build
     runs-on: ubuntu-latest
     steps:
@@ -35,7 +35,7 @@ jobs:
 name: jekyll
 on:
   pull_request:
-    branches: [master]
+    branches: [main]
   push:
     branches-ignore:
       - gh-pages

.github/workflows/lint.yml

@@ -14,8 +14,8 @@ jobs:
 name: super-linter
 on:
   pull_request:
-    branches: [master]
+    branches: [main]
   push:
     branches-ignore:
       - gh-pages
-      - master
+      - main

README.md

@@ -15,7 +15,7 @@ To develop locally run:
 
 ## Publishing
 
-Push updates or merge a pull request to the master branch and CircleCI will
+Push updates or merge a pull request to the main branch and GitHub Actions will
 take care of the rest.
 
 

project.md

@@ -266,7 +266,7 @@ git push
 
 ### GitHub Actions
 
-To trigger automated test runs everytime you push to master, or create a pull request, or push an update to a branch associated with a pull request do the following.
+To trigger automated test runs everytime you push to main, or create a pull request, or push an update to a branch associated with a pull request do the following.
 
 Copy the following contents into the file .github/workflows/ruby.yml:
 

project0.md

@@ -58,7 +58,7 @@ You webpage must include:
 ### Verification Script
 
 The `project0.py` script in
-<https://github.com/scalableinternetservices/ucsb_website/tree/master/scripts>
+<https://github.com/scalableinternetservices/ucsb_website/tree/main/scripts>
 can be used to automatically verify that your webpage meets the necessary
 requirements.
 

project1.md

@@ -126,7 +126,7 @@ __Note__: Please do not do any load testing from this machine.
 ### Verification Script
 
 Please use the following script to verify your web application:
-[https://github.com/scalableinternetservices/ucsb_website/tree/master/scripts#project-1-verification-script](https://github.com/scalableinternetservices/ucsb_website/tree/master/scripts#project-1-verification-script)
+<https://github.com/scalableinternetservices/ucsb_website/tree/main/scripts#project-1-verification-script>
 
 ## Questions To Answer
 

project2.md

@@ -212,7 +212,7 @@ Please review the template project README for development and deployment instruc
 ### Verification Script
 
 Please use the following script to verify your web application:
-[https://github.com/scalableinternetservices/ucsb_website/tree/master/scripts#project-2-verification-script](https://github.com/scalableinternetservices/ucsb_website/tree/master/scripts#project-2-verification-script)
+<https://github.com/scalableinternetservices/ucsb_website/tree/main/scripts#project-2-verification-script>
 
 ## Required Tools
 

project3.md

@@ -398,7 +398,7 @@ CORS. A copy of the client, with CSS and JavaScript separated can be found at:
 And, while you can view the source in the browser, it might be more convenient
 to see it on GitHub:
 
-<https://github.com/scalableinternetservices/ucsb_website/tree/master/project3/chat>
+<https://github.com/scalableinternetservices/ucsb_website/tree/main/project3/chat>
 
 __Note__: The logic of this client is written 100% in JavaScript and as such it
 serves as a poor example of code to copy since you can better accomplish the

slides/2021w/01_course_introduction/index.html

@@ -47,7 +47,7 @@
 <https://github.com/scalableinternetservices/ucsb_website/>
 
 Slide source:
-<https://github.com/scalableinternetservices/ucsb_website/tree/master/slides/2021w/>
+<https://github.com/scalableinternetservices/ucsb_website/tree/main/slides/2021w/>
 
 ---
 

slides/2021w/03_http_servers/index.html

@@ -267,7 +267,7 @@
 .right-column[
 Combination of the two techniques.
 
-Master process spawns processes, each with many threads. Master maintains
+Parent process spawns worker processes, each with many threads. Parent maintains
 process pool.
 
 Processes coordinate through shared memory to `accept()` requests.

slides/2021w/04_application_servers/index.html

@@ -326,7 +326,7 @@
 
 - "On MRI, there is a Global VM Lock (GVL) that ensures only one thread can run Ruby code at a time. But if you're doing a lot of blocking IO (such as HTTP calls to external APIs like Twitter), Puma still improves MRI's throughput by allowing IO waiting to be done in parallel."
 
-- "Puma also offers 'clustered mode'. Clustered mode forks workers from a master process."
+- "Puma also offers 'clustered mode'. Clustered mode forks workers from a [main] process."
 
 - "In clustered mode, Puma can 'preload' your application. This loads all the application code prior to forking."
 

slides/2021w/07_agile_tdd_pairing/index.html

@@ -880,7 +880,7 @@
 
 # GitHub Flow
 
-1. Ensure your master branch is up-to-date with the remote (often called
+1. Ensure your main branch is up-to-date with the remote (often called
    `origin`)
 
 2. Create a new branch for your feature (often called a `feature branch`)
@@ -899,15 +899,15 @@
 
 8. If there are test failures (you've set up a CI system, right?) fix them
 
-9. Merge the branch to master when everything is good-to-go
+9. Merge the branch to main when everything is good-to-go
 
 __Note__: We neglected the _deploy_ phase just prior to merging.
 
 ---
 
 # GitHub Flow Commands
 
-## Ensure your master branch is up-to-date with the remote
+## Ensure your main branch is up-to-date with the remote
 
 ```bash
 git pull
@@ -939,11 +939,11 @@
 Recall what we want to reconcile our changes regularly. Feature branches should
 be no more than a day or two out-of-sync with their parent branch.
 
-If you want to reconcile your changes without merging to master, a __git
+If you want to reconcile your changes without merging to main, a __git
 rebase__ is very useful:
 
 ```bash
-git rebase master feature_branch
+git rebase main feature_branch
 ```
 
 .center[![git rebase](git_rebase.png)]
@@ -957,7 +957,7 @@
 consider an interactive rebase:
 
 ```bash
-git rebase -i master
+git rebase -i main
 ```
 ]
 .right-column60[

slides/2021w/09_server_caching/index.html

@@ -597,11 +597,11 @@ <h3>Submissions</h3>
 Let's compare the performance of the demo app with and without caching.
 
 The subsequent graphs were generated using Tsung against a deployment of the
-`master` branch (without caching) and against a deployment of the
+`main` branch (without caching) and against a deployment of the
 `server_side_caching` branch (with server-side caching) using the default rails
 caching mechanism (memory).
 
-The `master` branch intentionally includes no optimizations.
+The `main` branch intentionally includes no optimizations.
 
 ---