diff --git a/workshops/images/hadley-wickham.jpeg b/workshops/images/hadley-wickham.jpeg new file mode 100644 index 0000000..686dd06 Binary files /dev/null and b/workshops/images/hadley-wickham.jpeg differ diff --git a/workshops/r_in_production.qmd b/workshops/r_in_production.qmd index a5cb25f..d8b731e 100644 --- a/workshops/r_in_production.qmd +++ b/workshops/r_in_production.qmd @@ -1,35 +1,39 @@ --- -title: Add workshop title here +title: R in Production author: - - name: Instructor 1 name + - name: Hadley Wickham affiliations: - - name: Instructor 1 affiliation - - name: Instructor 2 name (remove if single instructor) - affiliations: - - name: Instructor 2 affiliation + - name: Posit description: | - 1-sentence summary of workshop. -categories: [add, comma, separated, categories] + Learn how to write robust R code that both works reliably in production, and when it fails, is easy to debug. +categories: [r, production] --- # Description -Full workshop description goes here. Multi-paragraph ok. +What it means to put R in production varies tremendously from organisation to organisation. +However, I believe that there are common principles that you can learn to improve your code, regardless of the precise details of what production means for your organisation. + +This workshop is organised around three big differences between running a local script on your computer and putting your code into production: + +- **Not just once**: production code isn't a one-off script; it runs repeatedly, and needs to run reliably even as the environment around it (e.g. R package versions and input data) changes. How can you ensure that code continues to run reliably months and years after you wrote it, and when there's a problem it clearly reports on it. +- **Not just your computer**: production code doesn't run on your computer. It typically runs on some other server where you can't interactively experiment. This poses particular challenges for authentication and debugging. +- **Not just you**: the responsibility for production code is typically shared across a team. How can you ensure that you're all working together as effectively as possible, sharing code and best practices, and continuing to get better at your job over time. # Audience This course is for you if you: -- list at least +- Get frustrated debugging R code that's running on another computer. -- three attributes +- Struggle keep your code running reliably as packages and data change over time. -- for your target audience +- Want to generally improve the quality of your production code. # Instructor(s) -| | | | -|------------------|------------------|-------------------------------------| -| ![](images/name-lastname.jpg) | | Instructor bio, including link to homepage. | +| | | | +|-------------------|-------------------|------------------------------------| +| ![](images/hadley-wickham.jpeg) | | Hadley is Chief Scientist at Posit PBC, winner of the 2019 COPSS award, and a member of the R Foundation. He builds tools (both computational and cognitive) to make data science easier, faster, and more fun. His work includes packages for data science (like the tidyverse, which includes ggplot2, dplyr, and tidyr)and principled software development (e.g. roxygen2, testthat, and pkgdown). He is also a writer, educator, and speaker promoting the use of R for data science. Learn more on his website, . | : {tbl-colwidths="\[25,5,70\]"}