Minor typos. (#588)

This commit is contained in:
Nina Munkholt Jakobsen 2018-06-20 09:59:31 +02:00 committed by Hadley Wickham
parent 5c78fb7ca5
commit fe883cb46a
2 changed files with 10 additions and 10 deletions

View File

@ -28,7 +28,7 @@ knitr::include_graphics("screenshots/rmarkdown-knit.png")
## Output options
Each output format is associated with an R function. You can either write `foo` or `pkg::foo`. If you omit, `pkg` the default is assumed to be rmarkdown. It's important to know the name of the function that makes the output because that's where you get help. For example, to figure out what parameters you can set with `html_document`, look at `?rmarkdown::html_document`
Each output format is associated with an R function. You can either write `foo` or `pkg::foo`. If you omit `pkg`, the default is assumed to be rmarkdown. It's important to know the name of the function that makes the output because that's where you get help. For example, to figure out what parameters you can set with `html_document`, look at `?rmarkdown::html_document`.
To override the default parameter values, you need to use an expanded `output` field. For example, if you wanted to render an `html_document` with a floating table of contents, you'd use:
@ -53,7 +53,7 @@ Note the special syntax if you don't want to override any of the default options
## Documents
The previous chapter focussed on the default `html_document` output. There are number of basic variations on that theme, generating different types of documents:
The previous chapter focused on the default `html_document` output. There are a number of basic variations on that theme, generating different types of documents:
* `pdf_document` makes a PDF with LaTeX (an open source document layout
system), which you'll need to install. RStudio will prompt you if you
@ -88,15 +88,15 @@ output:
## Notebooks
A notebook, `html_notebook`, is a variation on a `html_document`. The rendered outputs are very similar, but the purpose is different. A `html_document` is focussed on communicating with decision makers, while a notebook is focussed on collaborating with other data scientists. These different purposes lead to using the HTML output in different ways. Both HTML outputs will contain the fully rendered output, but the notebook also contains the full source code. That means you can use the `.nb.html` generated by the notebook in two ways:
A notebook, `html_notebook`, is a variation on a `html_document`. The rendered outputs are very similar, but the purpose is different. A `html_document` is focused on communicating with decision makers, while a notebook is focused on collaborating with other data scientists. These different purposes lead to using the HTML output in different ways. Both HTML outputs will contain the fully rendered output, but the notebook also contains the full source code. That means you can use the `.nb.html` generated by the notebook in two ways:
1. You can view it in a web browser, and see the rendered output. Unlike
`html_document`, this rendering always includes an embedded copy of
the source code that generated it.
1. You can edit it in RStudio. When you open an `.nb.html` file, RStudio will
automatically recreate `.Rmd` file that generated it. In the future, you
will also be able include supporting files (e.g. `.csv` data files), which
automatically recreate the `.Rmd` file that generated it. In the future, you
will also be able to include supporting files (e.g. `.csv` data files), which
will be automatically extracted when needed.
Emailing `.nb.html` files is a simple way to share analyses with your colleagues. But things will get painful as soon as they want to make changes. If this starts to happen, it's a good time to learn Git and GitHub. Learning Git and GitHub is definitely painful at first, but the collaboration payoff is huge. As mentioned earlier, Git and GitHub are outside the scope of the book, but there's one tip that's useful if you're already using them: use both `html_notebook` and `github_document` outputs:
@ -113,7 +113,7 @@ output:
You can also use R Markdown to produce presentations. You get less visual control than with a tool like Keynote or PowerPoint, but automatically inserting the results of your R code into a presentation can save a huge amount of time. Presentations work by dividing your content into slides, with a new slide beginning at each first (`#`) or second (`##`) level header. You can also insert a horizontal rule (`***`) to create a new slide without a header.
R Markdown comes with three presentations formats built-in:
R Markdown comes with three presentation formats built-in:
1. `ioslides_presentation` - HTML presentation with ioslides
@ -158,7 +158,7 @@ Any HTML format (document, notebook, presentation, or dashboard) can contain int
### htmlwidgets
HTML is an interactive format, and you can take advantage of that interactivity with __htmlwidgets__, R functions that produce interactive HTML visualisations. For example, take the __leaflet__ map below. If you're viewing this page on the web, you can drag the map around, zoom in and out, etc. You obviously can't do that on a book, so rmarkdown automatically inserts a static screenshot for you.
HTML is an interactive format, and you can take advantage of that interactivity with __htmlwidgets__, R functions that produce interactive HTML visualisations. For example, take the __leaflet__ map below. If you're viewing this page on the web, you can drag the map around, zoom in and out, etc. You obviously can't do that in a book, so rmarkdown automatically inserts a static screenshot for you.
```{r}
library(leaflet)
@ -209,7 +209,7 @@ knitr::include_graphics("screenshots/rmarkdown-shiny.png")
```
You can then refer to the values with `input$name` and `input$age`, and the code that uses them will be automatically re-run whenever they change.
I can't show you a live shiny app here because shiny interactions occur on the __server-side__. This means you can write interactive apps without knowing JavaScript, but it means that you need a server to run it on. This introduces a logistical issue: Shiny apps need a Shiny server to be run online. When you run shiny apps on your own computer, shiny automatically sets up a shiny server for you, but you need a public facing shiny server if you want to publish this sort of interactivity online. That's the fundamental trade-off of shiny: you can do anything in a shiny document that you can do in R, but it that requires someone to be running R.
I can't show you a live shiny app here because shiny interactions occur on the __server-side__. This means that you can write interactive apps without knowing JavaScript, but you need a server to run them on. This introduces a logistical issue: Shiny apps need a Shiny server to be run online. When you run shiny apps on your own computer, shiny automatically sets up a shiny server for you, but you need a public facing shiny server if you want to publish this sort of interactivity online. That's the fundamental trade-off of shiny: you can do anything in a shiny document that you can do in R, but it requires someone to be running R.
Learn more about Shiny at <http://shiny.rstudio.com/>.

View File

@ -52,11 +52,11 @@ Much of the good advice about using lab notebooks effectively can also be transl
* If you want your code to be reproducible in the long-run (i.e. so you can
come back to run it next month or next year), you'll need to track the
versions of the packages that your code uses. A rigorous approach is to use
__packrat__, <http://rstudio.github.io/packrat/>, which store packages
__packrat__, <http://rstudio.github.io/packrat/>, which stores packages
in your project directory, or __checkpoint__,
<https://github.com/RevolutionAnalytics/checkpoint>, which will reinstall
packages available on a specified date. A quick and dirty hack is to include
a chunk that runs `sessionInfo()` --- that won't you let easily recreate
a chunk that runs `sessionInfo()` --- that won't let you easily recreate
your packages as they are today, but at least you'll know what they were.
* You are going to create many, many, many analysis notebooks over the course