 So I will be talking about the Mercury Framework and Mercury Framework is a tool for converting Jupyter Notebooks into web applications. And you know, we all know the Jupyter Notebook as a set of cells and the outputs and the cell can be a markdown text or a Python code. And it is quite a popular tool. Here you have a chart with number of IPNB files on GitHub. And on Y-axis you have 10 million. So no, the number of files is in millions. And there is a drop at the end of 2020 year because GitHub changed the way they indexed the repositories. And GitHub stopped to index inactive repositories. But you know, still you have millions of notebooks on the GitHub. So very popular tool. And the Jupyter Notebook is very popular for scientific computations, for data science tasks, for machine learning and for quick prototyping. And you know, you can do in Jupyter Notebook every step, for example, from machine learning pipeline because you can do some initial data exploration in notebook. You can do some visualization in notebook. You can clean and then prepare your data. And you can, for example, train machine learning model in Jupyter. So you know, there are many use cases for Jupyter. But there are also many surprising use cases for Jupyter. So for example, you can create a full Python package in Jupyter Notebooks. There is an NBDAF package for this. And it will help you to create documentation in Jupyter to publish your package from Jupyter. And you know, it all can be done in Jupyter. You can create books with Jupyter. There is Jupyter Book Project for this. And for example, you can write blocks with Jupyter. There is a Nikola package for this. And you know, you can ask yourself, what is the most important part of the notebook? And you know, for developers, it is code. And for non-technical users, it is the output. And you know, I have a feeling that Jupyter Notebook was not created for sharing the results. Why? Because it is hard to share results with non-technical users from Jupyter Notebook. Because you cannot share, you know, the notebook file with non-technical users. And why? Because first of all, they need to understand Python. So they need to know Python to understand your code. And then they need to have the local environment to run the notebook. So you know, they need to have Python. They need to have packages. They need to have hardware, for example, GPUs. And you know, they need to have access to the data. And very often it can be some remote database. So you know, it is hard to share notebook with non-technical users. And what are the current ways to share the notebook? For example, you can simply put the notebook in the GitHub repository. And you know, it is an easy solution. But you can, the GitHub will only render static HTML representation of the notebook. So there is no, you cannot interact with the notebook. You can use NB viewer to share the static HTML of the notebook. Or you can use MyBinder. But you know, it is not solution for non-technical users. It is rather solution for tech savvy users. Because MyBinder will launch for you full JupyterLab with all your code. So your end user needs to understand the Python. You know, there are plenty of online services that can set up for you, the environment. And they come with a lot of packages already installed. But still, you need to know, your end users, they need to know the Python to use them, to use them with your notebook. There is an amazing program called NBconvert for converting notebooks into HTML or PDF files. But you know, it is hard to update such a notebook. Because if you do some changes, then you need to export this to HTML or PDF and send, again, static representation of the notebook. And if you would like to have interactive representation, then you need to write an application for this. But I will talk in the next slide. You can also create the PowerPoint presentation. But this form of presentation of the results is very easy to understand for non-technical users. Then they like presentation. But creating presentation from Jupyter notebook outputs requires a lot of manual work from the developer, from the data scientist. And presentations are static. Okay, so you can create PowerPoint presentation from your notebook. And if you would like to have interactive results, then you are forced to rewrite all your results from the notebook into some UI or web framework. And there are plenty of only Python web frameworks to show your results as an interactive web app. So for example, there is IP widgets with Voila, Plotli, Dash, Streamlit or Panel. But all of them require from you to write some UI code. Okay, so they cannot turn your notebook into web app without changing the code. And that's why I created a Mercury. And Mercury is a tool for converting notebooks into web applications. And it can be dashboards, reports, web apps, slides or even REST API. And this presentation is an example of an app made with Jupyter notebook and Mercury. And thanks to this, for example, you can change the slides during the presentation. So for example, you have a string Hello Dublin here. And the greeting string is a variable in the Python. And I can change this during the presentation. I just provide new value and click Run. And the whole presentation is recomputed during the show. And you can even update chart. So for example, here is a chart with a lot of blue dots. And if I would like to have more dots with different color, for example, orange, then just click Run. And the whole presentation will be recomputed. And after computation, you will have the result. And you can continue. And how to use Mercury. It is pretty simple. Here you have, I will show you an example. Here you have a very simple notebook with two cells. So in the first cell, you have two variables, year and greetings. And in the second cell, you have just print with greetings. And the year end, Chesh, is a Hello in Polish. And you can very easily convert this into a web application. So you need to add YML header. And here you have an example of YML header. It needs to be inserted at the top of the notebook. And here you have the title and description of your application. You have a parameter show code set to false. So we will hide the code. And we have two widgets, two parameters, year and greetings. Term parameters, year and greetings. And you see that the name of the widget is exactly the same as a variable name in the code. And the year is a slider. We have labeled select year and the value 2022. And the greetings is a select. Select greetings label and the value is Chesh. And there are also other choices. And you need to install Mercury. And it can be easy done with PIP. And then you just run Mercury, run in the directory with your notebook. And you will have a local server running. And your user can, you can change something in the widgets and click Run. And the whole notebook will be recomputed. And only output will be showed to you. And as I said, the name of parameters must be the same as the variables that you would like to control with the widgets. And the YML configuration is very simple. In this slide, you have almost all parameters that can be included in a YML header. So we have title and description of the application. You have show code parameter to decide to show or hide the code. There is a share parameter to make the application private. There is output parameter. So your app can be app slides or REST API. There is a schedule parameter that accept the Chrome tab string. So you can set automatic execution. There is a notify parameters where you can send executed notebook to some users. And there is a params. So in the params, you define the widgets. And currently, we have six widgets implemented. Text, select, slider, file, numeric, and checkbox. And my favorite is file, because you can easily create the web application with file upload widget. And your end user can upload file with some data. And your notebook will prep, will process the data and show results for end user. And you can very simply do this. It is only three lines of YML configuration. So very simple. And as I said, there is a run command in Mercury that converts all notebooks in the directory into app apps. And there is also a watch command that might be helpful during the development that is constantly checking for updates in your notebook and refreshing the Mercury website with the latest version of your notebook. So it might be useful for development. OK, and some features of Mercury. So there is an app gallery built in, so you can serve as many notebooks as you want. So you are not limited to only one notebook per server, but you can use multiple notebooks on one server. You can easily set a custom welcome message. So in the previous slide, you see there is a welcome message. But you can change this with some custom markdown. So just add welcome.md file in the same directory as your notebooks. And you will have custom welcome message. You can easily download executed notebook as a standalone HTML file. Just click the button. And also, we support exporting to PDF. So also, just click a button and you will have PDF with your notebook. There is an execution history feature. So all of your execution are stored in a database. So you can easily go back to your previous execution and check the results. And just select the run number from execution history. We support outputting files. So your notebook can create files. And you can make them available for download and users. So you just add the output widget with a name and just write files to this output directory. And all files will be available to download. So there is a special view to download files created by notebook in the Mercury. So very easy to share files produced by notebook. And it is very easy to add authentication for your notebook. So only authenticated users can see the notebook. So just add share private to the YML header. And you can also share with only selected users. Just add the user list with their emails or user names. And it will be shared only with selected users. And this is how it looks that you have a login view. And user needs to login to see private notebooks. Schedule link is very easy because you have scheduled parameter that accept the crop string. That's all. And you can send the executed notebook as a PDF or HTML to selected emails. So it can be quite useful for building automated reporting system based on Jupyter notebook. And this is example of the mail that was automatically sent from Mercury with PDF notebook. You can very easily embed the notebook on any website. So I even embed the Mercury inside Mercury. And it was very easy just to add an iframe with address of the app. And a few words about the architecture. So when talking about the architecture, first I will tell you how the architecture looks when you add a notebook to the Mercury. So we are using NVConvert to change notebook to HTML. And we have some Python parser for YML header. And we parse this information and store information about widgets in the database base. And when the user executes the notebook, we have a front end written in TypeScript with React. And the notebook is in the main part of the screen. And on the left, there is a sidebar. And when the end user changes something in the widgets and click Run button, the JSON request is created with widgets values and notebook ID. And this request is sent to the back end. And on the back end, we have Django server. Of course, in Python. And Django server creates the task for salary. And in the background, the widgets values are injected into notebook code. And we use NVConvert to execute the notebook. And when the HTML representation is ready, we send it back to the front end. And deployment is very easy because it is based on Django. So you can basically deploy it anywhere that anywhere where Python is available. So my favorite platform for deployment is Heroku because you can deploy with one command, command git push Heroku main, and that's all. And from additional files, it only requires a cross file from you. And it is one line of command. And I have many apps running with Mercury on Heroku. You can also deploy it on any cloud provider with Docker compose, just Docker compose app. And it will be running. We also provide the Docker compose with support for HTTPS with Let's Encrypt support. And as I said, it can be deployed anywhere where you can run Python. And I even deploy this on HuggingFace, Spaces, even HuggingFace, Spaces doesn't support Mercury. It only supports Streaming and Gradio. But still, it supports Python. So I can deploy it there. And the Mercury has a dual license. So the core of the Mercury is AGPL3. So it is the 95% of the features. And there is also commercial license with additional features, for example, authentication. And we provide dedicated support and allow customization for commercial license users. And I choose such licensing to provide long sustainability for the framework. And I will show you some more demos right now. So for example, here is very simple notebook with year greetings and some name. And you can select some year, select the greetings and click Run. And the whole notebook will be executed with new parameters. So you see that the values from widgets are injected into the notebook. And the whole notebook is executed with new parameters. You can easily create the dartboards with Mercury. And here is a dashboard that is checking every minute Bitcoin price and displaying it as a dashboard. So after one minute, this value should be updated. So we can go back here in a minute. Here is another example of the notebook, a little bit more complex. This notebook is doing the get request to the Binance exchange to check the Bitcoin price. And this notebook is running with show code set to true. So you see the code of the notebook. But I have the same notebook with show code set to false. So you only see the output. So you don't see the code cells. OK. You can go back to the dashboard. And no, it's not updated. So we will need to wait. But let's go to the final slides. OK. And the future development for Mercury. I would like to add preheated kernels and caching. So right now, when a user run the notebook with new parameters, it takes about one second to start a new Python kernel. So I would like to add preheated kernels. So the running notebook will be faster. And I would like to add caching because many times, for example, you can run a notebook with large neural network or you will run the notebook with large data set. And then you will need to wait every time you execute the notebook. But I think the caching can be very easily added in the current architecture. I would like to add the support for the plain Python files. So not only notebooks can be converted to web apps, but also Python files. I would like to add support for other languages. For example, Julia should be pretty simple to add. I would like to add better layout for outputs because right now you have cell below the cell. And it will be nice to have some columns, for example, to put charts on different columns. And I would like to provide a cloud offering with one click deployments because not all users would like to set up their own server. OK. And that's all. Thank you. That's some link, link for Mercury, GitHub, link for this presentation. And the whole presentation is running on Heroku at europyton.herokuapp.com. That's all. Thank you. OK, about two minutes for questions if anyone wants to come up. Thank you very much for that presentation. It's wonderful. Just a really quick, daft question. I have notebooks on Google Colab. Can I use this to export it to PDF and HTML? Yes, I think yes. But you cannot do this directly from Colab. But you will need to download Colab files, Colab notebooks to have them locally. And then you can use Mercury to serve them. Thank you. How would you handle the fact that different notebooks have different requirements in terms of Python libraries when you're hosting all of them on the same server? Great question, great question. So right now there is only, let's say, one kernel handled by Mercury. But maybe in the future I will add support for running multiple kernels. But right now you have only one kernel per server. So all notebooks that are served on the single server, they all need to have the same requirements. One last quick question. Hi, great. Looks cool. So you mentioned that you could go back in time and look at previous run numbers. If you had large notebooks, does that become a storage issue or is that something that you need to keep an eye on? No, I don't think so. So what do you mean by large notebook? Yeah, no, I just was wondering, are you storing, so every time you run, are you storing the output of those notebooks physically? And can they start to build up over time if you're running a new notebook every minute? Yeah, so I store every executed notebook on some hard drive, on storage, and you can easily go back to it. Yeah, OK, yeah, that's all I was going to say. Thank you, looks good. Thank you so much for your talk. Thank you.