Last updated: 2020-10-22
Checks: 7 0
Knit directory: rr_tools/
This reproducible R Markdown analysis was created with workflowr (version 1.6.2). The Checks tab describes the reproducibility checks that were applied when the results were created. The Past versions tab lists the development history.
Great! Since the R Markdown file has been committed to the Git repository, you know the exact version of the code that produced these results.
Great job! The global environment was empty. Objects defined in the global environment can affect the analysis in your R Markdown file in unknown ways. For reproduciblity it’s best to always run the code in an empty environment.
The command set.seed(20201021) was run prior to running the code in the R Markdown file. Setting a seed ensures that any results that rely on randomness, e.g. subsampling or permutations, are reproducible.
Great job! Recording the operating system, R version, and package versions is critical for reproducibility.
Nice! There were no cached chunks for this analysis, so you can be confident that you successfully produced the results during this run.
Great job! Using relative paths to the files within your workflowr project makes it easier to run your code on other machines.
Great! You are using Git for version control. Tracking code development and connecting the code version to the results is critical for reproducibility.
The results in this page were generated with repository version b1ec62c. See the Past versions tab to see a history of the changes made to the R Markdown and HTML files.
Note that you need to be careful to ensure that all relevant files for the analysis have been committed to Git prior to generating the results (you can use wflow_publish or wflow_git_commit). workflowr only checks the R Markdown file, but you know if there are other scripts or data files that it depends on. Below is the status of the Git repository when the results were generated:
Ignored files:
Ignored: .Rhistory
Ignored: .Rproj.user/
Untracked files:
Untracked: README.html
Untracked: exercise.rmd
Untracked: figure/
Unstaged changes:
Modified: analysis/_site.yml
Note that any generated files, e.g. HTML, png, CSS, etc., are not included in this status report because it is ok for generated content to have uncommitted changes.
These are the previous versions of the repository in which changes were made to the R Markdown (analysis/programming.rmd) and HTML (docs/programming.html) files. If you’ve configured a remote Git repository (see ?wflow_git_remote), click on the hyperlinks in the table below to view the files as they were in that past version.
| File | Version | Author | Date | Message |
|---|---|---|---|---|
| html | 366d288 | jean997 | 2020-10-22 | Build site. |
| Rmd | 3180fcb | jean997 | 2020-10-22 | wflow_publish(all = TRUE) |
| html | 3180fcb | jean997 | 2020-10-22 | wflow_publish(all = TRUE) |
| html | 971cbb5 | jean997 | 2020-10-21 | Build site. |
| Rmd | 34cf544 | jean997 | 2020-10-21 | wflow_publish(all = TRUE) |
| html | b0d3bd7 | jean997 | 2020-10-21 | Build site. |
| Rmd | 3e16a7b | jean997 | 2020-10-21 | add pipelines, programming, workbooks |
Avoid modifying data “in place”.
Try not to open your data in Excel which can introduce errors like converting cells to dates. Analysis and data processing in Excel is very error prone and hard to track.
Consider saving the MD5 checksum for data you want to remain unaltered. The MD5 sum for a file is a character string that results from running the contents of the file through a hashing algorithm. If the contents change (even a little) the MD5 sum will change which gives you a quick way to know that something has happened to your data. In linux you can generate the MD5 sum with md5sum. If you want to be able to check on the data later, save the sum to a new file and then use the md5sum with -c to check.
md5sum myfile.txt > myfile.md5 ## Save the MD5 sum
md5sum -c myfile.md5 ## Check if the MD5 sum has changedBecause I am an R programmer a lot of these are given with sort of an R cadence but apply more or less as well for Python.
If you need to do the same task more than once write a function.
If you have written more than one function, make a package. R Pakcages by Hadley Wickham is great and will show you how to do it.
Document your code! Document your package using roxygen2 (see Chapter 10). Later write some vignettes so you can remember how to use it and so others can easily figure it out.
Include parameter checks in your functions. If you know properties about the inputs like that they should be positive or the dimensions of two inputs should match, check that and have your function error if something unexpected is provided. In R you can use the functions warning(), stop() and stopifnot() to give your user feedback.
Consider adding unit tests to your code using testthat for R.
If you want, you can make a website for your package with pkgedown. pkgdown will take all the documentation for your package and turn it into a website.
RStudio makes a lot of the other reproducibility tools easier including Git/GitHub and RMarkdown.
These tips are specifically for code that you will save a run again either at the command line using Rscript or as part of a package. If you are using R interactively these don’t apply (except the last one).
Avoid changing the working directory (setwd).
If you are sourcing in other R scripts, consider making a package instead or turning your analysis into a pipeline.
Be careful if you are having R run commands at the command line via system. Again, you might think about using a pipeline tool that will keep track of external steps for you.
Avoid removing variables from the workspace with rm. This can make it hard to debug later and set you up for future errors.
Avoid hard coding input and output files/parameters. It’s better to pass these in as options. This can help prevent you from overwriting results without realizing it and save you from errors if you move something.
If working interactively, avoid saving your workspace (when exiting you will be asked if you want to save or in RStudio you can set a default). If a workspace is saved (.RData exists), it will be loaded the next time you start R in that directory. If you don’t notice, now you have variables in your workspace from the previous analysis!
sessionInfo()R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.5 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/libopenblasp-r0.2.20.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] workflowr_1.6.2
loaded via a namespace (and not attached):
[1] Rcpp_1.0.5 rstudioapi_0.11 whisker_0.4 knitr_1.30
[5] magrittr_1.5 R6_2.4.1 rlang_0.4.7 stringr_1.4.0
[9] tools_4.0.3 xfun_0.18 git2r_0.27.1 htmltools_0.5.0
[13] ellipsis_0.3.1 rprojroot_1.3-2 yaml_2.2.1 digest_0.6.25
[17] tibble_3.0.3 lifecycle_0.2.0 crayon_1.3.4 later_1.1.0.1
[21] vctrs_0.3.4 promises_1.1.1 fs_1.5.0 glue_1.4.2
[25] evaluate_0.14 rmarkdown_2.3 stringi_1.5.3 compiler_4.0.3
[29] pillar_1.4.6 backports_1.1.10 httpuv_1.5.4 pkgconfig_2.0.3