Chapter: how to 'spadesify' existing code

[eliotmcintire]

1. Data inputs
   • Identify all data inputs
   • For each
     • Put the data in the cloud
     • Use prepInputs for each one
2. Evaluate code for conceptual groupings
   • e.g., "Data Preparation", "Data munging", "Data analysis", "Forecasting", "Report generation"
   • Modularize them, i.e., separate these chunks so that they are not intertwined
   • Decide whether these are "different SpaDES modules" or events in a single SpaDES module. We tend to separate "Data Preparation" into 1 or more modules, "Analytical" module, "Predict/Forecast" module.
3. Visualization
   • Convert any visualizations (e.g., plot, ggplot, hist etc.) to use SpaDES.core::Plots which can be "turned on, off, told to create .png etc." without an if statement.
4. newModule
   • Create a newModule
   • copy and pasting code from one chunk (a good place to start is a Data Preparation module) into the Init function.
5. Outputs
   • Decide on which objects that the code creates that should be "globally" available to another module e.g., the Data Analytics module
   • Add sim$ to EVERY time that object is created (i.e., it will be on the left hand side of an assignment) and subsequently used.
   • Add each of these to createsOutput in the metadata
6. Inputs
   • Decide on which objects that the code uses i.e., is expecting from "outside" of the module
   • Add sim$ to EVERY time that object is used (i.e., it will be on the left hand side of an assignment) and subsequently used.
   • Add each of these to expectsInput in the metadata
   • Use helpers to identify the inputs ... if using Rstudio, select the entire code chunk and then select Menu - Code - Extract Function and it will identify all the "inputs". There are often "false positives" that can be deleted, like package prefixes (e.g., it will identify terra as an input if it sees terra::rast)
7. Packages
   • Identify all the R packages that are necessary for your code
   • add these to reqdPkgs element in metadata