Econ 380 Book Project
March 10, 2024 08:37 PM CDT
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.
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 are deleted once they are no longer needed).
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)
- alt - (hold alt and type the minus sign): insert assignment 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 comment 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, open the file _bookdown.yml and update the 3 URLs to replace “YOUR REPO NAME” with the name of your repo (your repo name is the long string of characters starting with BP, e.g., bpChAnV5Nc1FpF8P0y). Doing this is what allows you to view your book in GitHub Pages and click on the icons near the top to get to your code. This is something needed to grade your BP chapters. Thus, if you don’t make this change in _bookdown.yml, any chapters you submit will receive a grade no higher than “Redo” until you update these URLs.
Third, 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.
When you submit a chapter, try to build all chapters unless there’s a good reason not to (you can’t get a chapter to run and need to come ask questions). To do this, you can just comment out whatever rmd_files:
line you have in _bookdown.yml so that it builds the entire book. If you want to exclude a specific chapter, you can either list all the other chapters in rmd_files:
or you can change the name of that file to start it with an underscore (files that start with an underscore are ignored).
Fourth, get started on your first chapter. 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.
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 for later on (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).
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:
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.
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][Intro_to_the_Tidyverse].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 DC interface is a bit picky. For example, in one of the chapters, it wanted group_by(continent, year)
and didn’t accept group_by(year, continent)
, even though these two produce the same thing. 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.