This is great! I have a lot of tools built in notebooks that I'd like to be able to share with non-technical collaborators, and have been procrastinating building a UI in Flask or Django as I'm really not interested in front-end stuff. This is a fun and simple way to deploy that won't be a distraction from collection and analysis I actually enjoy. I look forward to using it!
The Mercury framework was designed to make notebooks sharing easy. You don't need to build UI. Just define the widgets in the YAML header. Widgets are directly connected to variables in Python code. You can share notebook with non-technical users and hide the code (show-code: False). The user can tweak widgets and execute the notebook.
Additional features for sharing:
- user can download notebook as PDF or HTML,
- you can schedule notebook execution, and send executed notebook as PDF attachment in email notification,
- adding login view to notebooks is simple, just add `share: private` to YAML
Mercury has a different architecture. The Voila keeps the live kernel and connection to UI (using Tornado framework). To use Voila you need to add widgets (with ipywidgets) to the notebook (mix UI code with analytics code).
The Mercury generates UI based on the YAML header (very simple, no need to mix UI with analytics code). When user tweaks widgets values, the whole notebook is executed with new parameters and converted with nbconvert (using Django + Celery). Mercury can serve multiple notebooks to multiple users on one server. It has option to export notebook to PDF or HTML. You can schedule the notebook execution with crontab string (for example `schedule: '30 8 * * 1-5'`) and add email notifications. You can easily add authentication to notebooks. It was designed to make notebook sharing fast and easy.
What is more, I'm thinking about including Voila into Mercury. So you will be able to serve Voila apps with Mercury. The end-goal is to make notebooks sharing easy.
YMMV, has any technologist found a dashboard useful?
I've had a very bad history with dashboards. All I've seen get ordered up by nontechnical leadership, not looked at, and involved endless fiddling with painful corporate applications.
The non-technical stakeholders I've had a good relationship with, I vend a SQL script/Jupyter Notebook and educate. They're happy to up-skill.
I've only had dashboards requested by users with a dysfunctional relationship with engineering, in companies where the data is irrelevant.
In environments where data matters, fast moving consumer goods, web, etc, stakeholders speak SQL/Jupyter. I've seen remarkably non-technological people learn SQL and query read replicas because they need sales aggregates.
In environments where data doesn't matter, dashboards are requested as a corporate power play.
A director who doesn't care about your project asks for a dashboard to assert their authority, and remind you your budget can be cancelled.
You are lucky! There are many people that don't want to touch any code. Setting up a Python environment locally might be a big pain. That's a huge blocker for notebooks sharing.
I treat dashboard as visualization part. What is more, visualized data is used to trigger further actions - for example, send alert email. Yes, I found them useful.
I quite like monitoring dashboards and use them frequently. Mainly for examining system health and debugging operational issues.
My previous team had some business metric charts/dashboards related to system we worked on that we reviewed weekly. Most weeks review was it looks normal and was pretty fast review. Occasionally we'd see an unexpected deviation in some top level metric and that could trigger follow up work. Ideally all interesting deviations an alert would catch, but alerts are never complete.
Most of dashboards I've cared for my team/department was primary user of. I have not made dashboards much for other stakeholders.
“I find your ideas interesting and would like to subscribe to your newsletter." Sadly, your common sense observations will get belittled by the growing crowd of Liliputians who seem to enjoy celebrating their ignorance.
Non-techies wielding SQL is a big advantage for sure, but a moderately complex dataset sends SQL aggregations complexity through the roof. While modern data warehouses can handle such queries, I can hardly imagine non-technical person being able to write it.
Ditto, although for my applications they are not live (typical business processes lag by a month or more). So most of my stakeholders are happy that I just send a monthly PDF with updates.
The endless tinkering is still requested with the static reports, but that is much easier to deal with than serving up dashboards and tinkering with that.
People that run businesses and care about data don't want dashboards, they want spreadsheets. Lately I've been having some success with creating "user friendly" data views in big query and giving out access to them with connected Google sheets. If anyone wants to make a nice graph, pivot table or add their formulas to the workbooks they're free to do so using a tool they're already familiar with. The the data is backed by the database and can update on its own so we're not constantly sending out new versions of exported files.
Generalizations or problematic, since so much of this depends on industry, company, and role.
I'm in an industry (education) where at-a-glance dashboards have a proven track record of dramatically improve learning outcomes. It turns out that:
(1) Teachers, while believing they know their students, actually don't. Teachers also regularly fail to grasp what students do and don't understand.
(2) Allowing teachers to monitor their students, both individually and classroom wide, leads to much better outcomes.
In the context of a classroom, teachers are busy, non-technical (and sometimes incompetent), so an at-a-glance view is critical. For an example of real-time dashboarding done well, see Learning Catalytics. It grew out of a highly-respected physics education research project (Peer Instruction, by Eric Mazur), and allows teachers to monitor student understanding during lecture. Showing where misconceptions exist allows for deeper dives and deeper conversation. There are many systems like it, and ample evidence of improved student growth when they're used.
That's very specific, I know, but there are similar examples in other industries I've worked in.
Real time monitoring during a live task is certainly a use case I've never thought of.
A very good point.
I remember a piece on programming education research awhile ago. Said education outcomes improved considerably if you constantly bombard students with multiple choice questions.
Administering that through a dashboard would be essential.
I see the relevant part seems to be the following, in the "Tip 4" section:
"""
The key to making demonstrations more effective is to make learners predict the outcome of the demonstration before performing it. Crucially, their prediction should be in some way recorded or public, e.g., by a show of hands, by holding up cue cards marked with A, B, C, or D, or by talking to their neighbour. We speculate that the sting of being publicly wrong leads learners to pay more attention and to reflect on what they are learning; regardless of whether this hypothesis is true, instructors should be careful not to punish or criticise students who predicted wrongly but rather to use those incorrect predictions as a spur to further exploration and explanation.
"""
That part has been replicated (see e.g. vicarious learning, from Derek Muller as well as Miki Chi, studies on Khan Academy in-video questions, etc.).
However, it's not the most relevant part. The most relevant part is simple use of active learning. The classic paper here is Hake (Interactive-Engagement vs. Traditional Methods: A Six-Thousand-Student Survey of Mechanics Test Data for Introductory Physics Courses). However, it's been replicated discipline-by-discipline (lots of papers in PNAS). Best summary is ICAP by Miki Chi. Miki didn't invent it, and ICAP isn't the most rigorous, but she's pretty good at these summaries.
Having students do anything beyond listening leads to huge improvements in student learning, basically no matter what it is. Some things lead to bigger improvements than others, of course. Even clicking a "next" button occasionally shows a (very modest) gain. For good interactive engagement, doubling of learning gains is a good lower-bound over passive listening.
There's a broad range of techniques which have significant learning gains beyond passive learning. Active recall is one of them. We have no clear sense of how they compare to each other or how they work in combination. There is ample evidence for active recall, but there is equally ample evidence for a dozen other techniques much like it. We don't have great studies comparing them side-by-side.
The best hypothesis for how they compare is ICAP, referenced. It's still a hypothesis. You can look at the evidence behind it.
Much of this is context-dependent too. Active recall is great for factoids. If you're trying to learn a date in history, memorize a word in a foreign language, or a formula in math, your best bet is a spaced repetition system (how you time active recall makes a big difference too; spaced repetition > simple active recall > passive recall).
If you're trying to understand a concept like force (in physics), what an integral means (in math), make sense of the tradition away from serfdom, or compare ethical systems between two cultures, active recall is almost irrelevant. At that point, the best methods are probably constructive and interactive learning.
In my mind, active recall is an excellent technique that's appropriate for the first lecture covering a topic.
Which is why I like it as a prompt in a lecture, not so much later on.
Constructive learning in my mind comes later.
Re: the balance between constructive learning and other types.
I feel that we often accelerate the students too quickly to constructive learning, whilst they can still benefit from rote learning some worked examples.
The balance between rote learning and "copying" worked examples, and constructive learning from first principles, is a very difficult one.
I truly think that, certainly for programming education, all my professional life I've gotten huge mileage out of genuinely copying in example projects and tutorials into a text editor.
I think we underestimate just how much students benefit from rote learning.
I think programming education would benefit far more from 19 year old rote learning from retired 65 year olds. I find the college education system is fairly broken, in that it deploys researchers who are excellent lecturers, but far too few 65 year olds.
And there's an ocean of extremely willing to teach 65 year olds out there.
honestly this is a nightmare'ish point of view for anything but hard science at senior level. The emotional environment of being monitored constantly is toxic. Control-oriented people gravitate towards constant monitoring in similar ways as the Executive and their Dashboard are described above. How can thinking and feeling humans delegate interaction in a learning environment to machinery ?
That can be true, but it's not true in this case. Eric Mazur's classroom is sort of a visitor sport -- people come from around the world to observe. I'd encourage you to do the same. It's very human.
As originally implemented, the technique was pretty simple:
- You give a traditional lecture
- Every five minutes or so, students are asked a question to see if they understand concepts
- The system peers students who answered differently to discuss. Students can change their answers at the end.
- The instructor and class see aggregated statistics (e.g. 90% of people answered 27, 5% answered 54, and 5% gave other answers)
- Based on the feedback, the instructor can do a deeper dive into places where there are common misconceptions
Today's class is very different. Mazur juggles all sorts of peer learning models, 360 reviews, etc. in ways which are superhuman. But that's the original model.
Most of the uses of formative assessment lead to classrooms feeling more personal, more personalized, and more human.
There are control-oriented systems which scare the heck out of me, like GoGuardian and Securely, but this isn't it. There is a complex ethics question of how to build systems which don't dehumanize students.
It's not voluntary. 100% of students are asked a question. In the eighties, this was entered into a classroom response system (a clicker where kids press a button on multiple choice) and an eighties-era computer would process their responses for an eighties-era dashboard, presumably using one of those $20,000 CRT projectors.
Today, it's cell phones and laptops, and they do a lot more than multiple choice. Students might be asked to highlight text in a passage (and the system shows a heatmap), to draw vectors, etc.
> I've only had dashboards requested by users with a dysfunctional relationship with engineering, in companies where the data is irrelevant.
Sry, but this completly ... not true! Maybe in your subjective business environment, but definitely not for the whole community of python users.
We are placed in a scientific environment, teamworking with highly dimensional data. Here there is not a single person who has time to tinker around with another ones code nor data structure.
This will be a great benefit for regular report sessions - THX to the author!
Streamlit[0] was created specifically to create dashboards for ML/data science groups, and I've found it pretty useful. I've used it for research (model inspection and development), as well as teaching and it's been pretty useful for that.
Dashboards are really useful when you’re trying to distribute a set of metrics that large numbers of people actually need to know and agree on in order to do their jobs. Most metrics aren’t like this, so there are a lot of bad dashboards, but they definitely have their place.
Edit: A good example of this is something like incoming shipments for a warehouse. Management all the way down to warehouse workers need to know what is slated for delivery, what’s already been delivered in the last few days, and what’s late.
You’re definitely right that metrics are often used as post-hoc justification of decisions already made.
An example of actual dashboard culture is AWS’s operational metrics meetings. The construction of the dashboards themselves is scrutinized just as much as any latency or availability metric (may God have mercy on your soul if use a pie chart or display the median of metrics without justification). And it’s actually useful for surfacing issues and knowledge sharing. The frequent cadence can be a big cause if stress though.
From the non-technical side: it isn’t necessarily that dashboards are not useful, it’s just that most people who want them don’t actually know what data is useful.
But to your point there's often a principal agent problem in larger organizations. A decision-maker wants to appear "data-driven" so asks for a dashboard because it costs nothing for them to ask--someone else does the work. And when the dashboard shows something different than expected they dismiss the concern or find a reason that the dashboard is "wrong."
there’s nothing inherent about why we cant port Shiny’s features into the Python ecosystem. what do you like most about Shiny that is missing? (from Mercury or otherwise)
Ehhhhh, I'm a Python guy, and I find all of the Python Shiny alternatives lacking. Shiny delivers an incredible amount of value per line of code. My experiments with Dash and Streamlit required a lot more boilerplate to get something running vs the R equivalent.
For dynamic data I build my dashboards with Flask and Plotly. However that is certainly a more involved process to migrate Jupyter notebook Python plots to JS plots.
For static data one can just export html(with embedded JS) from Jupyter notebook that uses plotly.
The main difference with quick solutions is the level of customizability.
Mercury works very well with Plotly (here is a demo https://mercury.mljar.com/app/7). If you need to choose between Flask+Plotly and Mercury I would strongly recommend Mercury because of the speed of development.
What do you mean by dynamic data? Do you need automatically fetch new data in time intervals? (Mercury has scheduling and auto-update built-in with 1 minute lowest time interval).
Re your HTML point, we've been hacking on a framework which lets you programmatically create and share data reports in Python which you might find helpful (https://github.com/datapane/datapane). It supports Plotly, Pandas, Altair, Folium, MPL, etc., and provides some neat layout components like pages, selects, columns, and dropdowns.
If you need anything or want some help, feel free to make an issue or ping me on leo [-at-] datapane.com
- Why won't the OSS version provide features like history of execution? It seems like those are pretty basic to adoption. I'm working on an open source project, and it'd be a nice tool to potentially integrate. The commercial license is of zero interest since it's, well, all open-source.
- Why don't you sell the OSS version as well (e.g. for people who want to support you, or who want support)?
- Do you provide consulting services? Are they in the $50/hour range (just extrapolating from $200/year for up to 4 hours support)
- Why Django? I like Django, but it seems like using the same tech stack as Jupyter would make for simpler integration, administration, and lower TCO (plus the universe is going async)
- For presentation, the speed is an issue. Regeneration takes a while (I'm playing with the demo on Hugging Face). It's not quite adequate for interactive presentation. I do really like the concept of making presentations in Jupyter.
- And on that topic, the biggest gap I have is with interactive front-ends. I'd like to be able to somehow connect notebooks (both for dashboards and otherwise) for data munging to data visualization frameworks like D3. Jupyter is nice. Observable would be nice if it were open-source. There's a mile-high wall between the two.
- What is your project? is it from data science space?
- Selling OSS might be a great idea. Didn't consider it. I thought the Personal Pro version ($199/y) will be good for persons that would like to support the project or just need a support/guidance.
- Yes, I do consulting services. I don't treat support hours in similar way as consulting. The support is for product that I love working on and I love supporting people using it.
- Django - I'm pretty good at Django. What is more, I wanted to use Celery for processing background tasks and scheduling. This gives an architecture that can handle large loads. The frontend is in React with TypeScript.
- Speed can be improved. There are many ways to better handle that (it is version 1.0). You can add Plotly charts to make presentation more interactive. The advantage of Mercury is that you can recompute all slides if needed.
I don't disclose my identity online, and I think if I posted the project (or a description), it would do that. If you're curious, I'm glad to reach out by email. It is a data science project, and potentially, high-profile if it goes well.
On a mile-high level, Mercury seems like a perfect fit for what I'm doing. Conceptually, it's exactly what I was looking for.
Diving into the code, the fit seems less great, for reasons which are incidental (and wouldn't be worth changing for one integration). I'm trying to constrain the number of technologies in the overall project, to make it maintainable and deployable, and you seem to be on a completely orthogonal stack.
So I'll keep diving in and trying to understand it better.
When I need to expose jupyter notebooks to non-technical users I put them on colab.research.google.com. It's a free, interactive, hosted Jupyter environment. It's not as slick as a dashboard, but it just requires an upload instead of maintaining a server.
We render jupyter notebooks, markown and html - we dont host running jupyter environments -> but we focus on making the experience of sharing with non-techies on your team easy. So can show/hide the code, get comments etc.
It might be a solution but not all python packages work with WebAssembly. The next problem might be connection to external data sources. You cant keep secrets in frontend code.
Good point about secrets. Fortunately everything I write is for "internal use only" at my workplace, or if it's a home project, then I share everything. But I can see having to warn a non-techie that you're giving something which could reveal secrets if they pass it on to a third party. Especially since the secret stuff will be invisible to them unless they ask.
We've been encouraging Graphistry users to look at Streamlit for the low-code side (and getting bundled into our next release for public+private pydata GPU dashboarding!) or Databricks dashboards. Then at the expense of significantly more code / complexity without going full Flask/Django, we generally recommend switching to Dash/Voila/etc for getting way more control. Mercury seems quite close to the Streamlit/Databricks side, which in our experience is right for many pydata dashboarding teams yet most tools don't really nail. It may even be on the path to one-upping streamlit on the simplicity side. Good job & will be tracking!
My initial reaction is that there’s a ton of lag on the initial gif. Makes me think this is going to be a cumbersome thing to work with. Is it representative of a typical task, whatever that means?
Surprised I hadn't heard of mplfinance. Similar code for econometric charts with bands and an annotation table with dated events would be useful and probably already exists somewhere. Maybe Predictive Forecasting libraries for time series already have something that could be factored out into a maintained package for such common charts? E.g. seaborn has real nice confidence intervals with matplotlib, too; though the matplotlib native color schemes are colorblind-friendly: "Perceptually Uniform Sequential colormaps" https://matplotlib.org/3.5.0/tutorials/colors/colormaps.html
> ContainDS Dashboards - JupyterHub extension to host authenticated scripts or notebooks in any framework (Voilà, Streamlit, Plotly Dash etc)
IIRC, ContainDS and Voila spawn per-dashboard and/or per-user Jupyter kernels with JupyterHub Spawners and Authenticators; like Binderhub ( https://mybinder.org/ ) but with required login and without repo2docker?
E.g. BentoML is built on FastAPI which is async (sanic) and built by the DRF people, but FastAPI doesn't yet have the plethora of packages with tests/ supported by the Django community and DSF Django Software Foundation.
78 comments
[ 2.7 ms ] story [ 140 ms ] threadAdditional features for sharing:
- user can download notebook as PDF or HTML,
- you can schedule notebook execution, and send executed notebook as PDF attachment in email notification,
- adding login view to notebooks is simple, just add `share: private` to YAML
The Mercury generates UI based on the YAML header (very simple, no need to mix UI with analytics code). When user tweaks widgets values, the whole notebook is executed with new parameters and converted with nbconvert (using Django + Celery). Mercury can serve multiple notebooks to multiple users on one server. It has option to export notebook to PDF or HTML. You can schedule the notebook execution with crontab string (for example `schedule: '30 8 * * 1-5'`) and add email notifications. You can easily add authentication to notebooks. It was designed to make notebook sharing fast and easy.
What is more, I'm thinking about including Voila into Mercury. So you will be able to serve Voila apps with Mercury. The end-goal is to make notebooks sharing easy.
Mercury github repository https://github.com/mljar/mercury
I've had a very bad history with dashboards. All I've seen get ordered up by nontechnical leadership, not looked at, and involved endless fiddling with painful corporate applications.
The non-technical stakeholders I've had a good relationship with, I vend a SQL script/Jupyter Notebook and educate. They're happy to up-skill.
I've only had dashboards requested by users with a dysfunctional relationship with engineering, in companies where the data is irrelevant.
In environments where data matters, fast moving consumer goods, web, etc, stakeholders speak SQL/Jupyter. I've seen remarkably non-technological people learn SQL and query read replicas because they need sales aggregates.
In environments where data doesn't matter, dashboards are requested as a corporate power play.
A director who doesn't care about your project asks for a dashboard to assert their authority, and remind you your budget can be cancelled.
I treat dashboard as visualization part. What is more, visualized data is used to trigger further actions - for example, send alert email. Yes, I found them useful.
My previous team had some business metric charts/dashboards related to system we worked on that we reviewed weekly. Most weeks review was it looks normal and was pretty fast review. Occasionally we'd see an unexpected deviation in some top level metric and that could trigger follow up work. Ideally all interesting deviations an alert would catch, but alerts are never complete.
Most of dashboards I've cared for my team/department was primary user of. I have not made dashboards much for other stakeholders.
Merely an observation about the dashboard industry.
That's where dashboards come in handy.
Certainly I would never expect people to be experts. SQL Group By is nontrivial.
The endless tinkering is still requested with the static reports, but that is much easier to deal with than serving up dashboards and tinkering with that.
https://www.amazon.com/Fisher-Price-DYW53-Rollin-Strollin-Da...
It's a kids toy that lets them pretend they're driving the car.
BTW, I love spreadsheets. Spreadsheets + Python is very powerful connection :)
I've been reasonably successful at creating a data environment for my company in which all the data is exposed through REST APIs.
The existing tooling for APIs in general is top notch. Also, you get a lot of architectural flexibility.
Generalizations or problematic, since so much of this depends on industry, company, and role.
I'm in an industry (education) where at-a-glance dashboards have a proven track record of dramatically improve learning outcomes. It turns out that:
(1) Teachers, while believing they know their students, actually don't. Teachers also regularly fail to grasp what students do and don't understand.
(2) Allowing teachers to monitor their students, both individually and classroom wide, leads to much better outcomes.
In the context of a classroom, teachers are busy, non-technical (and sometimes incompetent), so an at-a-glance view is critical. For an example of real-time dashboarding done well, see Learning Catalytics. It grew out of a highly-respected physics education research project (Peer Instruction, by Eric Mazur), and allows teachers to monitor student understanding during lecture. Showing where misconceptions exist allows for deeper dives and deeper conversation. There are many systems like it, and ample evidence of improved student growth when they're used.
That's very specific, I know, but there are similar examples in other industries I've worked in.
A very good point.
I remember a piece on programming education research awhile ago. Said education outcomes improved considerably if you constantly bombard students with multiple choice questions.
Administering that through a dashboard would be essential.
I would love to read more about that, if you happen to have a link to share.
I see the relevant part seems to be the following, in the "Tip 4" section:
""" The key to making demonstrations more effective is to make learners predict the outcome of the demonstration before performing it. Crucially, their prediction should be in some way recorded or public, e.g., by a show of hands, by holding up cue cards marked with A, B, C, or D, or by talking to their neighbour. We speculate that the sting of being publicly wrong leads learners to pay more attention and to reflect on what they are learning; regardless of whether this hypothesis is true, instructors should be careful not to punish or criticise students who predicted wrongly but rather to use those incorrect predictions as a spur to further exploration and explanation. """
However, it's not the most relevant part. The most relevant part is simple use of active learning. The classic paper here is Hake (Interactive-Engagement vs. Traditional Methods: A Six-Thousand-Student Survey of Mechanics Test Data for Introductory Physics Courses). However, it's been replicated discipline-by-discipline (lots of papers in PNAS). Best summary is ICAP by Miki Chi. Miki didn't invent it, and ICAP isn't the most rigorous, but she's pretty good at these summaries.
Having students do anything beyond listening leads to huge improvements in student learning, basically no matter what it is. Some things lead to bigger improvements than others, of course. Even clicking a "next" button occasionally shows a (very modest) gain. For good interactive engagement, doubling of learning gains is a good lower-bound over passive listening.
Not only active participation, but actively being forced to remember the knowledge, in a different format to the original, is the key.
Teaching another student is definitely an approach to this. But a gentle touch multiple choice question also works.
There's a broad range of techniques which have significant learning gains beyond passive learning. Active recall is one of them. We have no clear sense of how they compare to each other or how they work in combination. There is ample evidence for active recall, but there is equally ample evidence for a dozen other techniques much like it. We don't have great studies comparing them side-by-side.
The best hypothesis for how they compare is ICAP, referenced. It's still a hypothesis. You can look at the evidence behind it.
Much of this is context-dependent too. Active recall is great for factoids. If you're trying to learn a date in history, memorize a word in a foreign language, or a formula in math, your best bet is a spaced repetition system (how you time active recall makes a big difference too; spaced repetition > simple active recall > passive recall).
If you're trying to understand a concept like force (in physics), what an integral means (in math), make sense of the tradition away from serfdom, or compare ethical systems between two cultures, active recall is almost irrelevant. At that point, the best methods are probably constructive and interactive learning.
In my mind, active recall is an excellent technique that's appropriate for the first lecture covering a topic.
Which is why I like it as a prompt in a lecture, not so much later on.
Constructive learning in my mind comes later.
Re: the balance between constructive learning and other types.
I feel that we often accelerate the students too quickly to constructive learning, whilst they can still benefit from rote learning some worked examples.
The balance between rote learning and "copying" worked examples, and constructive learning from first principles, is a very difficult one.
I truly think that, certainly for programming education, all my professional life I've gotten huge mileage out of genuinely copying in example projects and tutorials into a text editor.
I think we underestimate just how much students benefit from rote learning.
I think programming education would benefit far more from 19 year old rote learning from retired 65 year olds. I find the college education system is fairly broken, in that it deploys researchers who are excellent lecturers, but far too few 65 year olds.
And there's an ocean of extremely willing to teach 65 year olds out there.
As originally implemented, the technique was pretty simple:
- You give a traditional lecture
- Every five minutes or so, students are asked a question to see if they understand concepts
- The system peers students who answered differently to discuss. Students can change their answers at the end.
- The instructor and class see aggregated statistics (e.g. 90% of people answered 27, 5% answered 54, and 5% gave other answers)
- Based on the feedback, the instructor can do a deeper dive into places where there are common misconceptions
Today's class is very different. Mazur juggles all sorts of peer learning models, 360 reviews, etc. in ways which are superhuman. But that's the original model.
Most of the uses of formative assessment lead to classrooms feeling more personal, more personalized, and more human.
There are control-oriented systems which scare the heck out of me, like GoGuardian and Securely, but this isn't it. There is a complex ethics question of how to build systems which don't dehumanize students.
The shy kids sit there and be quiet.
"Prompt" questions, like multiple choice, are a good way of encouraging reluctant students to come out of their shell."
Today, it's cell phones and laptops, and they do a lot more than multiple choice. Students might be asked to highlight text in a passage (and the system shows a heatmap), to draw vectors, etc.
They can't be trusted to dress themselves.
Sry, but this completly ... not true! Maybe in your subjective business environment, but definitely not for the whole community of python users.
We are placed in a scientific environment, teamworking with highly dimensional data. Here there is not a single person who has time to tinker around with another ones code nor data structure.
This will be a great benefit for regular report sessions - THX to the author!
[0] - https://streamlit.io/
Edit: A good example of this is something like incoming shipments for a warehouse. Management all the way down to warehouse workers need to know what is slated for delivery, what’s already been delivered in the last few days, and what’s late.
An example of actual dashboard culture is AWS’s operational metrics meetings. The construction of the dashboards themselves is scrutinized just as much as any latency or availability metric (may God have mercy on your soul if use a pie chart or display the median of metrics without justification). And it’s actually useful for surfacing issues and knowledge sharing. The frequent cadence can be a big cause if stress though.
https://aws.amazon.com/blogs/opensource/the-wheel/
Managing Oracle databases? Enterprise Manager Cloud Control.
Managing your investments? Schwab has a good interface.
But to your point there's often a principal agent problem in larger organizations. A decision-maker wants to appear "data-driven" so asks for a dashboard because it costs nothing for them to ask--someone else does the work. And when the dashboard shows something different than expected they dismiss the concern or find a reason that the dashboard is "wrong."
There's a neat overview of the landscape here https://www.youtube.com/watch?v=4a-Db1zhTEw
For dynamic data I build my dashboards with Flask and Plotly. However that is certainly a more involved process to migrate Jupyter notebook Python plots to JS plots.
For static data one can just export html(with embedded JS) from Jupyter notebook that uses plotly.
The main difference with quick solutions is the level of customizability.
What do you mean by dynamic data? Do you need automatically fetch new data in time intervals? (Mercury has scheduling and auto-update built-in with 1 minute lowest time interval).
If you need anything or want some help, feel free to make an issue or ping me on leo [-at-] datapane.com
- Why won't the OSS version provide features like history of execution? It seems like those are pretty basic to adoption. I'm working on an open source project, and it'd be a nice tool to potentially integrate. The commercial license is of zero interest since it's, well, all open-source.
- Why don't you sell the OSS version as well (e.g. for people who want to support you, or who want support)?
- Do you provide consulting services? Are they in the $50/hour range (just extrapolating from $200/year for up to 4 hours support)
- Why Django? I like Django, but it seems like using the same tech stack as Jupyter would make for simpler integration, administration, and lower TCO (plus the universe is going async)
- For presentation, the speed is an issue. Regeneration takes a while (I'm playing with the demo on Hugging Face). It's not quite adequate for interactive presentation. I do really like the concept of making presentations in Jupyter.
- And on that topic, the biggest gap I have is with interactive front-ends. I'd like to be able to somehow connect notebooks (both for dashboards and otherwise) for data munging to data visualization frameworks like D3. Jupyter is nice. Observable would be nice if it were open-source. There's a mile-high wall between the two.
- Selling OSS might be a great idea. Didn't consider it. I thought the Personal Pro version ($199/y) will be good for persons that would like to support the project or just need a support/guidance.
- Yes, I do consulting services. I don't treat support hours in similar way as consulting. The support is for product that I love working on and I love supporting people using it.
- Django - I'm pretty good at Django. What is more, I wanted to use Celery for processing background tasks and scheduling. This gives an architecture that can handle large loads. The frontend is in React with TypeScript.
- Speed can be improved. There are many ways to better handle that (it is version 1.0). You can add Plotly charts to make presentation more interactive. The advantage of Mercury is that you can recompute all slides if needed.
On a mile-high level, Mercury seems like a perfect fit for what I'm doing. Conceptually, it's exactly what I was looking for.
Diving into the code, the fit seems less great, for reasons which are incidental (and wouldn't be worth changing for one integration). I'm trying to constrain the number of technologies in the overall project, to make it maintainable and deployable, and you seem to be on a completely orthogonal stack.
So I'll keep diving in and trying to understand it better.
- host multiple notebooks,
- you can easily hide code,
- you can schedule notebooks,
- you can download notebooks as PDF,
- you can easily add authentication to the notebooks.
It all depends on your needs and project requirements.
https://about.kyso.io/
We render jupyter notebooks, markown and html - we dont host running jupyter environments -> but we focus on making the experience of sharing with non-techies on your team easy. So can show/hide the code, get comments etc.
[0] https://www.unite.ai/google-has-banned-the-training-of-deepf...
[1] https://news.ycombinator.com/item?id=31538595
We've been encouraging Graphistry users to look at Streamlit for the low-code side (and getting bundled into our next release for public+private pydata GPU dashboarding!) or Databricks dashboards. Then at the expense of significantly more code / complexity without going full Flask/Django, we generally recommend switching to Dash/Voila/etc for getting way more control. Mercury seems quite close to the Streamlit/Databricks side, which in our experience is right for many pydata dashboarding teams yet most tools don't really nail. It may even be on the path to one-upping streamlit on the simplicity side. Good job & will be tracking!
[1]: https://panic.com/blog/the-panic-status-board/
awesome-jupyter > Rendering/Publishing/Conversion https://github.com/markusschanta/awesome-jupyter#renderingpu... :
> ContainDS Dashboards - JupyterHub extension to host authenticated scripts or notebooks in any framework (Voilà, Streamlit, Plotly Dash etc)
IIRC, ContainDS and Voila spawn per-dashboard and/or per-user Jupyter kernels with JupyterHub Spawners and Authenticators; like Binderhub ( https://mybinder.org/ ) but with required login and without repo2docker?
Streamlit lists Bokeh, Jupyter Voila, Panel, and Plotly Dash as Alternative dashboard approaches: https://github.com/MarcSkovMadsen/awesome-streamlit#alternat...
Says here that mljar/mercury is dual-licensed AGPL: https://github.com/mljar/mercury
E.g. BentoML is built on FastAPI which is async (sanic) and built by the DRF people, but FastAPI doesn't yet have the plethora of packages with tests/ supported by the Django community and DSF Django Software Foundation.