Open maximlt opened 2 years ago
Hi @maximlt this looks like an excellent start, and thank you for sharing and taking the time to create the readme and video. I will give this for a test drive in the next few days and will have notes for our meeting next week. I'll also try to comment on the various Issues you have posted
Panel seems like a good solution. As you noted, there are a lot of advantages in serving a web application straight from a notebook, and Panel looks really great.
Apologies for the plotly/dash things that leaked into the segmentation codes. I will look into making that improvement in the original doodler
I watched the video also and the progress looks great! Also looking forward to the meeting...
Panel seems like a good solution. As you noted, there are a lot of advantages in serving a web application straight from a notebook, and Panel looks really great.
I think ultimately the code of the application would live in one or more Python scripts instead of in a notebook. It would just be easier to maintain, Github diff on a notebook are pretty difficult to read for instance. But the application itself could still be imported and viewed in a notebook.
Apologies for the plotly/dash things that leaked into the segmentation codes. I will look into making that improvement in the original doodler
Oh no worries and no apologies required! That wasn't so much change to do really.
What we usually recommend is for people do to initial exploration and development in whatever interactive environment they prefer, whether that's Jupyter, VSCode, or some other editor, and then to take any substantial bits of code and clean them up as general, fully documented separate python modules. The resulting notebook should then illustrate how to use things and show and explain how they fit together, leaving a lasting literate record of the main components that form an app. That notebook can then be launched as a standalone server if all that's needed is the final app, but then someone can run Jupyter on the notebook as well and see how everything fits together, putting them together a different way if they want or replacing some bits altogether. That way the resulting notebook tells a clear story that invites people into the development process (as opposed to an opaque "panel serve file.py" command that simply launches an app without any other way in), while not storing substantial code in notebooks (which is not a good idea as outlined above). As a rule of thumb, the notebook should invoke your code (with parameters and configuration), rather than implement your code; when you've achieved that using a good separation between a python module and a notebook, you'll have something that is maintainable, explainable, modifiable, and extensible!
Completely understood (thanks for explaining so clearly), and completely in line with my thinking
I'm opening this issue as a means to keep everybody informed (@dbuscombe-usgs, @rsignell-usgs, @jbednar, @jlstevens ) about the development of Doodler.
12/22/2021
You'll find in the README a short video that shows the content of the
doodler.ipynb
notebook when executed. In this notebook we've built a series of components that are then put together in an orchestrating class that:The final step consists in laying out the components/plots/views to form an application. You'll find a simple one in the notebook and a slightly more polished one that can be deployed (also from the notebook!).
(This way of building a web app, by iterating in a notebook and putting together small pieces/components, is really powerful!)
There's still work to do before the app is ready for production, most notably around its interfaces (input images, saved output, ...). We'll get the chance to discuss about that early next year!