Frequently asked questions

Course Workflow: Homework and Labs

RStudio Git Workflow

Working with Git in RStudio involves several key steps:

  1. Ensure you are on the main branch. Pull in remote changes by clicking the down arrow .
  2. Create a new branch by clicking the branch icon .
  3. Work on your documents and save frequently.
  4. Stage your changes by checking the appropriate boxes.
  5. Commit your changes by clicking Commit.
  6. Repeat steps 3-5 as needed.
  7. Push to GitHub by clicking the up arrow .
  8. Open a pull request (PR) on GitHub.
  9. Use the dropdown menu to return to main to avoid potential issues.

Command Line Git Workflow

If you prefer using the command line, follow these steps:

  1. Pull remote changes (optional but recommended): git pull
  2. Create a new branch: git branch -b <name-of-branch>
  3. Work on your documents and save frequently.
  4. Stage your changes:
    • For specific documents: git add <name-of-document1>
    • For all changed documents: git add .
  5. Commit your changes with a meaningful message: git commit -m "Descriptive commit message"
  6. Repeat steps 3-5 as needed.
  7. Push to GitHub: git push (follow any suggested command variations)
  8. Open a pull request on GitHub.
  9. Switch back to main: git checkout main

Homework Regrade Procedure

Regrade Eligibility
  1. Deductions must exceed 3 points and be related to content (not penalties).
  2. Errors can be corrected to potentially raise the grade to 7/10.
  3. Revisions and review requests must be submitted within one week of the initial review.

Regrade process:

  1. Locate the local branch for the specific homework assignment.
    • Check the “Pull Requests” tab in your GitHub repository if you can’t recall the branch name.
  2. Make necessary corrections to the files.
  3. Commit and push changes, ensuring the PDF is re-rendered if needed.
  4. Find the original PR for the assignment on GitHub.
  5. Add a concise, clear comment to the TA describing your changes.
  6. Click the recycling (🔁) button under “Reviewers” to request a review.

Common Git and Workflow Issues

master/main

“master” has some pretty painful connotations. So as part of an effort to remove racist names from code, the default branch is now “main” on new versions of GitHub. But old versions (like the UBC version) still have “master”. Below, I’ll use “main”, but if you see “master” on what you’re doing, that’s the one to use.

Start from main

Branches should be created from the main branch, not the one you used for the last assignment.

git checkout main

This switches to main. Then pull and start the new assignment following the workflow above. (In Rstudio, use the dropdown menu.)

You forgot to work on a new branch

Ugh, you did some labs before realizing you forgot to create a new branch. Don’t stress. There are some things below to try. But if you’re confused ASK. We’ve had practice with this, and soon you will too!

(1) If you started from main and haven’t made any commits (but you SAVED!!):

git branch -b <new-branch-name>

This keeps everything you have and puts you on a new branch. No problem. Commit and proceed as usual.

(2) If you are on main and made some commits:

git branch <new-branch-name>
git log

The first line makes a new branch with all the stuff you’ve done. Then we look at the log. Locate the most recent commit before you started working. It’s a long string like ac2a8365ce0fa220c11e658c98212020fa2ba7d1. Then,

git reset ac2a8 --hard

This rolls main back to that commit. You don’t need the whole string, just the first few characters. Finally

git checkout <new-branch-name>

and continue working.

(3) If you started work on <some-old-branch> for work you already submitted: This one is harder, and I would suggest getting in touch with the TAs. Here’s the procedure.

git commit -am "uhoh, I need to be on a different branch"
git branch <new-branch-name>

Commit your work with a dumb message, then create a new branch. It’s got all your stuff.

git log

Locate the most recent commit before you started working. It’s a long string like ac2a8365ce0fa220c11e658c98212020fa2ba7d1. Then,

git rebase --onto main ac2a8 <new-branch-name>
git checkout <new-branch-name>

This makes the new branch look like main but without the differences from main that are on ac2a8 and WITH all the work you did after ac2a8. It’s pretty cool. And should work. Finally, we switch to our new branch.

Improving Your R Programming Skills

Learning Approach

Learning to code is an active, immersive process. Simply reading books or watching videos is insufficient. To truly learn R:

  • Complete tutorials multiple times
  • Explore textbook code thoroughly
  • Question the rationale behind function choices
  • Experiment with different coding approaches
  • Break down and understand each line of code

Debugging Code

General Debugging Workflow

When your code doesn’t run:

  1. If the code runs but doesn’t produce expected results, see the code quality section.

  2. Read the Error Message

    • Error messages provide crucial debugging hints
    • Parsing them can be challenging but is a valuable skill

    Example:

    set.seed(12345)
    y <- rnorm(10)
    x <- matrix(rnorm(20), 2)
    linmod <- lm(y ~ x)
    ## Error in model.frame.default(formula = y ~ x, drop.unused.levels = TRUE): variable lengths differ (found for 'x')

    Notice the error about variable lengths and matrix dimensions.

  3. Consult Documentation

    • Use function-specific help (e.g., ?matrix)
  4. Search Online

    • Copy error messages into search engines
    • Remove specific, identifying information
  5. Seek Peer Help

    • Use class Slack channels
    • Prepare a minimal working example (MWE)
  6. Instructor/TA Consultation

    • Be prepared to show your code
    • Provide a reproducible example
Warning

When seeking help, always be ready to share your code or MWE.

Note: If the error cannot be reproduced, it is unlikely that anyone can help you effectively.

Crafting Minimal Working Examples (MWEs)

An MWE is a compact code snippet that:

  • Reproduces an error on any machine
  • Isolates the specific problem
  • Minimizes external dependencies

Benefits of creating MWEs:

  • Often helps you solve the problem independently
  • Reveals the root cause of issues
  • Makes it easier for others to help you

MWE Tips

  • Set random seeds for reproducibility
  • Use minimal, generic data
  • Include only essential code

Preparing an MWE is a valuable debugging skill. By stripping your problem down to its bare essence, you often uncover the root issue. For instance, the previous debugging example was an MWE: it used a fixed seed, ensured data reproducibility, and focused on a specific error.

For further guidance, consult:

Writing High-Quality Code

This is covered in much greater detail in the lectures. Here are key principles for writing clean, efficient R code:

  1. Use Script Files

    • Save and source scripts
    • Avoid console-only work
    • Treat R as a scripting language, not a calculator
  2. Avoid Code Repetition

    • Never copy and paste code
    • Define constants at the script’s beginning
    • Create reusable functions
  3. Function Design

    • Functions are easily testable
    • Verify inputs and outputs
    • Catch potential errors through comprehensive testing
  4. Error Types

    • Syntax errors (detectable by R)
      • Missing parentheses
      • Incorrect arguments
    • Logical errors (require thorough testing)
      • Require manual verification of results
  5. Avoid Magic Numbers

    • Always define constants
    • Make numerical values meaningful and clear
  6. Use Meaningful Names

    Bad example:

    data("ChickWeight")
    out <- lm(weight ~ Time + Chick + Diet, data = ChickWeight)

    Good example:

    data("ChickWeight")
    chick_weight_model <- lm(weight ~ Time + Chick + Diet, data = ChickWeight)
  7. Comment Strategically

    • Explain code that isn’t immediately clear
    • Focus on the “why”, not just the “what”

    Example of helpful commenting:

    # Calculate weighted average of chick weights, squared and adjusted
    chick_weight_summary <- with(
      ChickWeight,
      by(weight, Chick, function(x) (x^2 + 23) / length(x))
    )

Remember: Clear, readable code is as much about communication as it is about functionality.