NAMCr Sprint

[philipbaileynar]

Task 1

Fixing specific issues with the NAMCr package.

• 29

• 21

• 31

• 28

• 30

Task 2

More general testing of each API endpoint via NAMCr.

Iterate over all API endpoints (use NAMCr::cli() to see a list of the API endpoints) and call them repeatedly over as many permutations of data as possible. Philip will provide a table of API endpoints ranked by priority. The goal is to ensure that all endpoints operate without throwing an error; the most common of which is a bad formatting caused by an erroneous curly brace "{". It is recognized that Frank does not possess the context necessary to interpret the data returned. Therefore the goal is just to check for errors.

I see a few options for how best to provide the arguments to the endpoints:

1. Philip provides a CSV file for each endpoint containing arguments. For example, for the siteInfo endpoint Philip will provide a CSV of ~ 32,000 sites and Frank will load this CSV and iterate over each row, calling the siteInfo with the values from the CSV.
2. Some endpoints can be used to retrieve the list of inputs for other endpoints. For example, the sites endpoint can be used to get a list of all sites that are then fed into the siteInfo endpoint.
3. Philip could code a quick Python script(s) that spits out a giant R script with all the API calls. Frank would then just run this monster script in R Studio and investigate any errors. This avoids the need for Frank to learn the API endpoints and arguments.

A Little Context

The NAMCr package was written before the API was finished. By the time the API was complete we had introduced several endpoints that return data in new structures that cause NAMCr problems. The two suspected data structures that cause NAMCr problems are lists and JSON.

While we explicitly avoided using JSON data types in the API, new data that has been inserted since the system launch has included JSON in some fields. The API should be formatting this in a consistent way, but NAMCr appears to struggle in some cases.

[Feldspar5]

Option 3 above does suggest it would save time for Frank.

[philipbaileynar]

@Feldspar5 I just talked to Frank. We agreed to go with option 3 because:

• Avoids Frank needing to learn the system. He just runs the giant script of R commands.
• The giant script of R commands can be reused as a regression test in the future. We can quickly run the R commands after any change to the system to reveal if the change breaks an R command.

[Feldspar5]

Good news; I was hoping that was the chosen solution. I look forward to hearing what he discovers. Thanks