Overview

This overview provides a brief explanation of this book. This book has two main sections, DataCamp and Econometrics. Each is described below.

The DataCamp section is notes on DataCamp courses. Much of the content in these chapters is directly copy/pasted from DataCamp. Typically this is plagiarism, something important to avoid both at and outside of Lawrence. However, directly copy/pasted content is an important aspect of this BP and it isn’t feasible to put quotation marks around all of it. So, we will give credit where credit is due here. Let this sentence serve as attribution and citation: except for the portions of the DataCamp section that are my own notes supplementing the DataCamp content, which are indicated in red font using the “mynotes” html tag, all content comes directly from DataCamp and the author of this book is giving them credit for their content.

Note that the first two chapters are included as examples to give you an idea of what to do (and while reviewing that content might be helpful, you do not need to do those DataCamp courses.)

The Econometric section has chapters based on econometrics content covered in class. Content and data in those sections come from the sources discussed in those chapters. These chapters serve as a reference for important concepts and technical skills, as well as examples of how to implement them in R.

The first file in bookdown is always index.rmd (and the resulting output file, index.html, is the first file GitHub pages will display). Thus, this must be the first file of your book. This file has this overview and the General Notes section that follows (and initially there are brief instructions, but those can be deleted once they are no longer needed).

I have included a code-chunk in each chapter so that errors will display with yellow font and red background. Without this, an error will cause the book to stop building. By handling most errors using this code, you can still build the book even if you have an error. This makes it much easier to work with your BP. If you can’t get something to work, you can build it and then ask for help. However, make sure to look for errors in the output and fix them (unless the purpose of the line of code is to ask a question, or to demonstrate an error, which you’ll see in part of the Introduction To R chapter included as an example).

General Notes

Useful RStudio keyboard shortcuts

  • ctrl-alt-I: insert new code chunk
  • ctrl-shift-C: toggle comments to make text that isn’t a comment a comment and text that is a comment not a comment (works in and out of code chunks, but sometimes not if you highlight parts of both)
  • alt - (hold alt and type the minus sign): insert assignment operator (<-)
  • ctrl-shift-M: insert tidyverse pipe operator (%>%)

Use this page to add any other notes you think might be helpful for you later in the course or years from now (delete this sentence and everything below–but not above–after you’ve read the instructions that follow and done everything it tells you to do…I started you off with a few common keyboard shortcuts above…feel free to add to that list as well).

Instructions

First, read carefully the full BP instructions found in Canvas. Only a few small aspects of the instructions are included here.

Second, find the line in the file _bookdown.yml that starts: rmd_files: ["index.Rmd","01-Intro_To_R.Rmd","02-Intermediate_R.Rmd","03-Intro_to_the_Tidyverse.Rmd"]. It currently is proceeded by a hash tag. This makes it a “comment”, meaning it is ignored when you build your book. Try building your book and looking at the output. You should see many chapters. Now remove that hash tag and re-build your book. You should only see the first page generated from this index.Rmd file and the first three chapters. If you don’t want to build every chapter every time you click Build Book, you can use this command to build only the chapters you want to build. For example, rmd_files: ["03-Intro_to_the_Tidyverse.Rmd"] will only build that one chapter (this is the first chapter you need to work on, so you might want to start out with this). They will build in the order you list, so make sure to list chapters in order. Note that if you don’t include “index.Rmd”, your book won’t be visible from GitHub Pages.

Another way to have it skip a Rmd file is to rename the Rmd file to start with an underscore (“_”). Then you can rename the file again to remove the underscore when you want it to be included again. If you want to only build a chapter or a few, it is easiest to specify them using rmd_files. If you want to build all chapters except one or a few, it is easiest to rename the one (or a few) you want to skip with an underscore.

When you submit a chapter, try to build all chapters unless there’s a good reason not to (including a chapter is keep your book from building, and you need to come ask questions).

Third, get started on your first chapter (which is “03-Intro_to_the_Tidyverse.Rmd”). Your notes should have explanations and working code with actual working examples of most of what you learn. If you don’t have working code, your BP chapters won’t receive credit. We should see the code and the resulting output in your book. The Introduction To R and Intermediate R chapters provide an example so you know what it should look like.

As mentioned above in the Overview, for most DataCamp chapters the bulk of what you will do is work through the content in DataCamp and copy/paste into your book. This creates a great reference to use in the future (both in the course and when you use R in the future). Many parts are straightforward and don’t really require any additional comments, examples, explanations, etc. However, you’ll probably fine some parts less straightforward. When you have to figure things out, are confused by something, etc, don’t just copy/paste what you found confusing; you’ll likely find it confusing again in the future when you refer back to it. For these parts, add additional notes explaining the concept, filling in missing details, and whatever else helps it make more sense to you (note the “to you” part…these are your notes, and not everyone is going to understand or be confused by the same things, so people will need to add different notes in different places).

When you add your own notes supplementing what you copy/paste from DataCamp, put them in the “mynotes” html tag. That will make everything between the opening “mynotes” and closing “mynotes” tags have a red font. Don’t forget both the opening and closing tags. When you build the book, you’ll see that this paragraph is red (i.e., this is an example of how you do this). If you don’t know how to use html tags, see here. Then, once you understand how to use html tags in general, go into index.Rmb and find this paragraph to see how to use this mynotes html tag specifically.

In addition to text comments/explanations, you will also benefit from providing supplemental code examples. To understand how to do what they teach you in DataCamp, you often need to play around a bit with different examples (e.g., take what they give you and change it a bit to better understand how things work, use the same functions with a different dataset). You can also add these to supplement what you copy/paste from DataCamp. When you do this, put your examples in a new code chunk. Immediately before the code chunk that contains your own examples (i.e., not directly copy/pasted from DataCamp), include the following:

My Example:

## Then code you wrote yourself (not the DC copy/pasted code) goes in the code chunk right after that label

Later, when you (or me grading it) look through your book, it will be easy to distinguish between the text and code that comes directly from DataCamp, and what you added to help you better learn the material covered by DataCamp.

I will look for text explanations in the mynotes html tag, and the My Example: label before code, when I grade. To avoid getting a lower grade, make sure you include these elements in your book. This is sort of like making your these statement clear near the beginning of an essay. If the reader needs to dig for it, they’ll miss it. If I need to dig for the content you add, I’ll miss it. The mynotes html tag around text explanations and the My Example: label before code make it clear for me as your reader grading it.

Note that you can cross-reference headings (and sub-headings, and 3rd level headings, etc). For example, here’s a cross-reference to the Intermediate R chapter: Intermediate R. You can also cross-reference with a custom name, such as this is a link to the Intro to the Tidyverse chapter.1 You can also link to chapter/section numbers. See sections 1.2.5 and 2.1 for examples of that reference style.

If you ever find that a code chunk produces many (hundreds or more) lines of output, change it so that it doesn’t. An easy way to do this is to add %>% glimpse() or %>% str() at the end of the code that produces the many rows of output. That will display what we want to see in a compact but clear and pretty complete way. Sometimes people end up with output that is millions of lines long (literally) and then their book takes hours to load. Students have lost many days to this in the past. So if it gets really slow, look for long output and fix it.

Note that sometimes the DataCamp interface is a bit picky. For example, sometimes the order you do a few steps in doesn’t matter for the results, but it expects the code in a specific order. So if you think what you have is right but for some reason it’s not accepting it, you can try switching a few things like this. You can also just click show solutions on occasion. If you’re doing this for every exercise, you’re obviously not going to learn the material. But if you’re spending a long time to get through one exercise, it’s fine to show solutions, make sure it makes sense to you, and then move on.

You also might wonder why we’re not using the cache=TRUE knitr option. It’s great…when it works. Unfortunately, it often causes problems, and when it does, it often takes a long time to realize the problem is caching. Many of us have wasted many hours, only to later determine the culprit was caching. So, we don’t use that option.

I would leave the author as “380 Student” so that your BP remains anonymous, even when displayed online via GitHub Pages.

  1. See here for more details.↩︎