Week 1: Overview, Empathy and Persuasion, and a Bit of Git

R
Author

Robert W. Walker

Published

January 5, 2023

Updated: January 20, 2023 with a bit on shiny Meeting Date: January 9, 2023

Attribution for cover graphic: XKCD

Full Graphic

Following the presentation of an overview of the general plan for the course and our establishment of familiarity with one another, I will focus on three major topics for today, one leading into our next meeting in two weeks time (January 23, 2023).

Class Plan [Not Necessarily Chronological]

  1. An Overview
  2. Introductions, skills, and background
  3. On Empathy and Argumentation
  4. Git and version control
  5. Supplemental Topics

Readings:

  • An approach to argumentation

Kneupper, C. W. (1978). Teaching Argument: An Introduction to the Toulmin Model. College Composition and Communication, 29(3), 237–241. https://doi.org/10.2307/356935

A .pdf is available on WISE.

A short presentation

  • On Git

Jenny Bryan has an excellent, though dated, extended treatment of Git. It was distilled into a shorter article, Excuse me, do you have a moment to talk about version control?

The longer version is here

Version Control

What is it? That’s for software developers. Why is it an ideal tool for data science and data projects?

One of the most important ideas when collaborating: merge versus rebase.

It has a golden rule.

Key Tips

  • Thinking through .gitignore

The usethis package and usethis::git_vaccinate()

  • Primary data security through adding data/ to .gitignore.

Two supplemental topics:

  1. How to Read R Help

  2. Useful places for assistance: Stack Overflow, RStudio Forums

One Key Thing That’s on My Mind

winston-chang

This is a very nice comparison of the two methods. The shinylive via Github pages really is a neat feature.

A Little Quiz

What’s Wrong?

Homework

The first assignment will come in groups of 2. Here is what I want you to do.

  • First task? Find a partner to work on this with. Preferably, work with someone that you have not grouped with before; may as well expand your horizons.

  • Second task, each of you needs an individual github presence, if you do not already have one.

  • Third task, one or the other – the owner – of you needs to create a repository, you can call it what you want. The reason for groups is collaboration here.

  • Fourth task, if you created the repository, add your partner as a collaborator.

  • Fifth task, if you created the repository, create an RMarkdown or Quarto default file and commit it to the repository.

  • Sixth task, for the collaborator, obtain a local version of the repository.

  • Seventh task, edit the markdown or quarto file and add the following code chunk to the quarto or RMarkdown file:

library(tidyverse)
mtcars %>% summary

and knit the file to html

  • Eight task, the collaborator must (strong preference for staging here) commit and push their edits to the shared repository.

  • Ninth, the owner should integrate the changes their collaborator has made to the local repository via pull.

  • Tenth, the owner should add

mtcars %>% 
   ggplot() + 
   aes(x=cyl) + 
   geom_bar() + 
   theme_minimal()

to the quarto/RMarkdown file, knit to html, and commit and push their changes to the github repository.

  • Eleventh, the collaborate should integrate the changes to their local repository. Once this is complete, compress the directory that houses the repository, copy it to the local repository’s directory, and commit and push the changes.

  • Twelfth, the owner should integrate the changes so that the repository contains three files, an RMarkdown/Quarto source document, an html document, and a .zip file.

Deliverable: an email, identifying the members of the group and the URL of the repository. Because of commit histories, all the work, assuming it is staged, is contained in the repository for verification.