- excellent guidance for collaborative project teams (especially team leads) even if they're not open and not R
- What they forgot to teach you about R including some required reading:
- why you should use here::here() and not setwd() to make sure your code works anywhere
- why you should use (RStudio) p/Projects to manage your code
- how you should name data files to stay sane
- why you should not add anything to .Renviron or Rprofile unless you want to irritate team members
- and much more, although:
- we don't agree with keeping your data in your project. Data should be somewhere else, unless you're a .gitignore wizard and your data is small (and non-sensitive/non-commercial/public etc)
- using git(hub/lab) for version control (perhaps via usethis and knowing about ohshitgit just in case)
- using git branches as a way for different people to work on the same project without clashing
- Tom has blogged about this
- we have written a short guide
- HappyGit gives you the details
- ohshitgit may be required here too (but not if you've followed the instructions above)
- using git(hub/lab) issues as a way to manage your project - just like we did for the new ECCD website
- how to use drake to massively speed up and manage your workflow. This includes always:
- loading and processing all your data inside a drake plan in a .R file. So it only gets re-run if the code or data changes
- creating each of your output objects inside the drake plan. So they only get re-created if the code or data changes
- rendering your .Rmd report at the end of the drake plan. So you can pass the params in and report the output objects
- => the first time you run the plan it will build everything. The second time, e.g. after you fix a .Rmd typo, only the bits that have changed get re-built. Warning: drake can reduce the time it takes to run your code by an order of magnitude. This could seriously damage your tea & cake in-take...