-
-
Notifications
You must be signed in to change notification settings - Fork 12
Short, Medium, and Long Term Goals
Status: Done! 🎉
An MVP for this project will be able to:
- Run an instance of the website on localhost.
- The homepage of the will contain model outputs that incorporate data from the USGS API and the HOBOlink API. (Those outputs needn't be presented in the prettiest way.)
There are three short-term next steps after an MVP in order to have all the functionality of the website available beyond it simply working out of a terminal and calculating numbers in the most trivial of cases.
Status: Done! 🎉
The web application should be containerized and deployed to the cloud.
As a small non-profit, CRWA is sensitive to budgetary constraints, so we will want to utilize a free service if at all possible. And we do believe it is possible to spend $0 deploying this site: we believe that this website would be deployable through Heroku. We are not sternly wedded to Heroku, so if you have any suggestions for alternate hosting services that can deploy a Flask app for $0, please bring up suggestions during our weekly meetings!
Note: CRWA currently hosts its homepage on Weebly, which does not support custom server-side scripting. Therefore, we cannot deploy the flagging website alongside the CRWA homepage.
Status: Done! 🎉
If you look in the code base, you'll see there's a file called cyanobacteria.py. As of writing, that file is mostly empty. That file is there as a placeholder for eventually replicating functionality that's in their old PHP website that let them (manually) record cyanobacteria bloom events through a web form. My understanding is that this is not critical to an MVP, but it is definitely something we want to have ready in short order.
Note that this overlaps with developing a database: the Cyanobacteria stuff would need to be written into a database and retrieved from that as well.
Status: In progress. (75% done?)
In the MVP, we may not necessarily do much with the HTML. For example, in the MVP we might just output the __repr__ of a dict and that's that. As a short-term goal, at the very least, we want to translate the old flagging website's template into Jinja.
This is where things get fun, and we start making the website look like a real program.
Status: In progress. (75% done?)
The APIs take forever to call; we need to store the data in order to make it easier.
Status: In progress. (Halfway?)
Yes, eventually we will need to write tests for our code. This should be pretty self-explanatory: untested code is broken code.
Status: In progress. (Halfway?)
Because of who we are building this product for an organization that does not hire explicitly for coding experience in Python, we will eventually need to write a lot of comments and documentation aimed at maintaining the website and interpreting parts of the code that are bit more advanced. To the extent that we can, we should do this as we code. But somewhere in the medium-term phase of this project, we should really make sure the code is documented well. To some more veteran Python coders, the end product will end up looking over-commented.
In addition to adding lots of docstrings and comments, another thing we should do in this step is make sure that all errors are handled appropriately. This doesn't mean wrapping everything in try-except statements and skipping over errors, it means making sure that when errors do happen, the error messages that pop up are informative.
For documentation, we should also ask CRWA volunteers if they have any questions on how to run the website, and then make sure we document the answers to those questions. We should make sure the documentation on how to set up the website is extremely baseline, which means documenting ostensibly simple things like walking through how to install Python, how to set up pip virtual environments, and how to set requisite environmental variables. We really want to make sure that anyone can deploy this website.
Status: Done! 🎉
Status: In progress.
Eventually it might make sense, as we prepare for long-term goals, to make the model a REST API so it has a common and well-defined signature for interfacing with various services that use the model (the flagging site, and the Twitter app).
Status: Not started.
I'm not sure what else we'll want to do here, but in general, our medium-term goal is to focus on two things: first, making it into a real website. And second, making it a website that non-programmers can maintain.
These are all nice-to-haves.
Status: Not started.
Once we flesh out a real data pipeline, we can create a Twitter bot that connects to the data pipeline, and sends out notifications on the quality of the water.
Status: Not started.
Other watershed associations may be interested in what we have here. Can we make this product into something that all watershed associations around the globe can use?
Status: Not started.
For the short and medium term goals, we will be feeding in model coefficients hard-coded into the code.
In the long term, it would be nice if we could actually integrate model training more directly into how the website operates. This doesn't mean we need to have the website training on data every time it is deployed or overnight or whatever. All I am saying is it would be nifty if we had a function that, say, directly outputs the aforementioned yaml file instead of requiring manual placement of coefficients into said yaml file.