Now we're going to walk through exactly what is in this template, and how R Markdown is using these markup commands to generate our document. First we have the title and the author and the date that's shown what's called a YAML header and you can see now I've got two different outputs specified because I have knitted this document two different ways. I have knited it as both an HTML and a PDF. That is followed by these are called code chunks. They're little snippets of code, they're specified by the three backtick marks followed by a curly bracket and you will see the name of the code, the type of code that it is. This could be R, it could be Python, it could be any of several things. But in this case, we're going to be just using R for right now. This is the name of the chunks, so this tells me that this chunk is called setup and it's not going to be included in the output of my final document. But this tells me that it's setting the options chunk to have echo equals TRUE and we'll see what echo equals TRUE means. Double hash marks is a level 2 header. If I had put a third hashmark here, it would be a level 3 or one deeper down level in my document and we can see in our document what a header level 2 look like. Here is the title and then this is a level 2 header. Then all the texts that I had put is going to be printed and I can see that my link, you see I have a link here in my document which is started with the little brackets like that a less than and greater than the mark and that gives me a link which is the same as executable from my HTML document that gets knitted. Here I've specified a bold word, the next chunk I have named cars and what happens when I execute this chunk is that R Markdown repeats the commands that are in the chunk and executes them, and shows the output. This is the summary of the built-in cars dataset so this tells me it has two variable speeds and whatever dist stands for and gives me some summary information about those. Then I have another level 2 header, including plots, and says you can also embed plots for example, so it's going to put all my text, and in this case, I have named the chunk pressure and set echo equals FALSE. What this means is it will not include the code plot of pressure, it won't produce those words but it will execute it and show me the results. Here's the plot that is of the built-in dataset pressure. Look at this, it's echo equals FALSE with this background on it, I can do an inline code by single backtick marks and put code inside of my text that's in my document. We will conclude this lesson with some discussion about things that you should always do in your R Markdown, and things you should never do, and some helpful tips. We've talked before about reproducibility, so you want to use relative and not absolute paths. For instance, if I put../filename that's going to go up one level in my path structure. If I do /data/ filename.csv, this would access the file called filename.csv in the data folder of your current directory. Now you can always put any data you are using, in a data folder. You might want to check if the data folder doesn't exist, then you can create it. You want to show the code, for any assignment you're returning in unless you're instructed otherwise. You want echo equals TRUE to be on, you also want to just comment on any lines that you're using for debugging your code. That way if you need to turn them back on later, it's simple to just uncomment them. You always want to include your test cases in their output when you need them and at the very end of your R Markdown document, you should add an R chunk. Sometimes you want to do this in the appendix but that chunk should have the command sessionInfo(). This will document into your document the exact levels of the packages. Which package are you're using and what addition of it are you using? That way you can always come back and reproduce your document by loading the correct version of those packages. Things you should never do in R Markdown. You should never use setwd to set the working directory. You should never install packages in your R Markdown. You want to library those packages that you're going to use in the document and it's nice to do that all of those packages up in the very first section of your document so that someone using your document can see what packages they will need and decide whether they want to install those or not, but you don't want to install packages on someone else's machine by accident. Some helpful tips. Name your code chunks. Each name must be unique and the reason I'd like to name my code chunks is that then when the document knits, it tells me which chunk it's knitting, and so if it has problems, I know immediately how far it got the document and where the problem was occurring. I suggest you knit your documents frequently. Every time you make any substantial change or do any significant coding, try knitting it again and make sure it still works. Because a lot of times, what you don't want to do is get the whole document done, try to knit, it doesn't knit and then you don't know where to go. Knit every few commands. Also, if you try out your commands and the console first, and then put them in the code chunk that would be helpful, and if you go to our studio, you will see that if I go to, we found a document here. If I'm in [inaudible] document, and I want to try some things out over here and let's see. I've got some things working and then I want to use them. I can go to history and I can highlight the ones that I want, and put it in console. What I frequently do is I will try them out in the console, and then I will copy them to the source, and that will put them where my cursor is inside of my R chunk. That's one way to build up your code, by trying things in the console first that you know are going to work and then copy them over. Last but not least, if you can't get your document to knit, and you know what chunk is causing the problems, you can add the option [inaudible] equals FALSE in the chunk header until you can debug it. This way you can continue working on other things, say you're working on a homework assignment and this one piece won't knit, put eval equals FALSE, welcome the other pieces then come back to that one and try to fix it. Worst case, you have to turn it in without that chunk actually working, but your instructor can still see what you have been able to do in the code, and maybe help you with debugging it.Thank you.
