Taylor Rodgers - PKGlobal || Manufacturing Meetup (Democratizing an ML model ) || Posit

Well, thank you. Hello, everyone. My name is Taylor Rodgers and welcome to the R in Manufacturing webinar. On today's talk, I'm going to tell you about how we use RStudio's Shiny product to help a manufacturing client save money and improve quality. I'm going to share some of the project requirements, or at least the part that I'm actually allowed to share with you guys.

I'll do a brief app walkthrough of the key functionality that was used in facilitating the app rollout to the plant workers on the plant floor. I'm going to tell you a little bit why we went with Shiny as opposed to many other data science application tools on the market. And I'll also do a brief code walkthrough at the end. Now, if you're wanting to know the exact step-by-step programming details of this application we're going to be demonstrating, I'm not going to go into too much detail about that today. But we are actually going to post a how-to article after this talk that will actually teach you how to replicate what I show you today. So if that's something that's going to interest you, I'll encourage you to check that out afterwards. And we'll also have some time for questions at the end if you have any.

About the speaker

Let me give a little bit more of an introduction of myself, though. As you already know, I'm Taylor Rodgers. I'm a senior data scientist and project lead at PK Global. In my role, I primarily build data science applications, usually those that incorporate machine learning. My primary tool for doing that is Shiny. I have a master's in applied statistics from the University of Kansas Medical Center. And as you can tell by the picture of me holding a book, I'm a writer as well. I write a lot about data science topics. The book I'm holding there is called Data Work. This is a book I actually just released a month ago. If that's a subject that interests you, you can actually buy it on my website or on amazon.com.

Another project I'm working on, this one I think will probably be more interesting to people on the call, is R Programming in Plain English. This is a book I'm writing. I'm about 90% of the way done. I only got one chapter left, but it's actually available for free online to those who need it. It explains R Programming in as non-technical of a way possible to people who don't have any programming experience but find that they need to use R for their academic research, or maybe they just started as a data analyst and need to learn a good statistical programming language. So if that's you, that's the book for you, and I strongly encourage you to check it out.

Project background

But that's enough about me. Let's talk about why we're here today. We're here to talk about R manufacturing. What does that actually mean in this context? Well, we built Shiny Apps, basically, for our client. For those who don't know, Shiny App is an interactive program that runs on top of R. The one you see here in the screenshot is the one I'm going to demonstrate for you in a little bit, but you can use Shiny to build data visualizations, dashboards, data entry input forms for databases. There's a lot of possibilities with this tool. But there's actually only so much that I'm allowed to share with you about this project. The reason is, is our client is a defense contractor, and for that reason, they very highly value secrecy, and they gave us their blessing to talk about this project, but we can only share with you key information about it. So for example, I'm not actually allowed to tell you what our client's name is. I'm not allowed to tell you the product that they build, and I'm not even allowed to tell you the inputs we use on the algorithms that we included in this project.

That might have some of you asking, what's the point of this webinar? Then how do you present a case study on manufacturing when you can't even mention the product or the client? And I think that's a fair criticism if you're thinking of it, but ultimately, what I'm hoping to show you today is not necessarily anything about our client's product, but how we use Shiny to improve their manufacturing process, and why Shiny was the tool to do it.

But the project requirements that I can share with you though, they're kind of broad. Our client approached us, and they said they wanted to build predictive algorithms that could be used to predict the performance of a product based on the chemical inputs. So in this process, the manufacturing process itself takes about a day, but at the very beginning of that, there is a mixing process of various elements and chemicals. And that process takes about 60 to 120 seconds, about two minutes. And it's not just about mixing element A with element B, a ratio of 70 to 30%. What actually impacts the performance of their product is the rate at which those chemicals are injected. So you might have element B injected at a rate of five grams per second at the beginning of that two-minute process, and then it increases to 15 grams per second as it proceeds. That ultimately affects the quality of the product that they're building.

They were hoping that we would develop machine learning algorithms that could better predict the performance of those products based on how long and how fast those chemicals were injected during that process. The other key detail that they wanted us to deliver with this project, the other big requirement, is that they wanted to democratize the machine learning models. Rather than have an office manager very far away from the plant, run these calculations with the model, and then send it to the plant workers and say, do this, they actually wanted to build, they wanted to provide those machine learning models in such a way that the plant workers could actually make their own predictions. So the person doing the mixing could do the prediction and then make their decisions on how to mix those chemicals together and at what speed.

This is a very important feature because even though the actual mixing process takes maybe one to two minutes, the process that follows that afterwards with continuing the production process can take a whole day. It's very energy intensive, it takes a lot of time, and not only that, if they do it wrong, they actually lost most of the resources that they spent on it. It's a lot harder to recycle those resources to get it right the next time. So it's very important to find a way to put this model in front of the plant workers so they could make the predictions in real time and go about their jobs afterwards in the best way possible.

App walkthrough

How exactly do you do that? Well, you have to build an interactive user interface. That's what the client approached us and say, they actually had a mock-up and said, we'd like you to build this application for us. As anyone knows who's worked in this industry for a long time, it's actually very rare that a client will ever come up to you and tell you the exact thing that they want and the requirements. But we got very fortunate in this in the sense that we were working with a client who could think out things like that ahead of time and provide a plan for us to follow.

But let me actually show you the part of the app that I am allowed to share with you. This right here is the Shiny app. You might remember from that screenshot I showed earlier. And this is not the actual application we showed the client or we delivered to the client. This is the application that you can build on that how-to article we'll post later.

These three tables right here are not really relevant to this demonstration, but whenever you follow that how-to article, you'll actually be able to see how what you're building impacts things on the back end with these three tables that's meant to be a guide for that. The part that was on the application that we deliver our client is what you see on the left here. This may look like just a normal line graph that reports something like on any other dashboard or application, but what this actually is, it's actually the inputs that feed into the predictive algorithms that we build. If you notice on the x-axis, we have time. In this particular example, it's actually seconds, 70 seconds worth of time. And you see speed on the y-axis. This represents the rate at which those chemicals were injected that I talked about earlier. And each one of these individual dots actually represents model inputs.

Now, how would the plant workers on the plant floor actually use something like this? Well, what the client said they wanted us to do was give the ability to the plant workers to click a dot and move it up here. And what they're doing is changing the model inputs that feed into the algorithm. And the reason why they were able to use this so intuitively is that it actually mimics the process that they would use for the chemical injections themselves. This is very similar to what they're going to see on their own machinery interface when they actually do the mixing.

So that was the big ask that they had. They also said they wanted the ability to hand type the input. So what you see here, you can get pretty close to 50. And let's just say the plant worker wanted to make it exactly 50. We wanted to give them the option to do that as well, to give very precise numbers and also maybe change this to something more precise as well. That was the other key requirement that they had for this user interface. And even though you only see a shiny matrix here, that's what that's called, and you see a plotly graph here, there are actually three of these. There are three of these plots that were used as model inputs for the different chemicals that they represented.

So how that would actually work on the client app is after they selected all their model inputs and dragged it and placed it where they wanted it to go, they would hit a button that said simulate, it would pass that to the model parameters, and then they would see the predicted performance on the right hand side. It would give them an indication on whether they were meeting the requirements for that particular mixture that they needed.

And not only that, they also had these certain rules that we had to make sure the end user followed. Like for example, you can't really have a negative time, at least in this context, I guess you can't really have negative time in any context. But for example, if they wanted to try to change the zero value to something further left, it would have to revert back to zero. Same with this last value of 70, we had to make sure if they try to change that to something sooner, it would kick it back to 70. These rules were not only in place because they reflected the reality of the actual chemical mixing, but because we had to do that for the model inputs, we had to make sure the model inputs followed those rules before they got inserted into the algorithm. Otherwise, we would have gotten incorrect conclusions.

Why Shiny?

Now, having said that, why was it that we ultimately went with Shiny? How did Shiny become the tool that we built for this project? And, you know, our client actually came to us directly and said that they wanted to use a Shiny app. But even if they had come to us and said, these are the requirements we have, this is the interface we want you to build, what tool would you recommend we use to build that? We probably still would have said Shiny anyways.

Now, why is that? I actually want to explore that question for a moment, because this is something I've often asked in my own career of myself. Up until maybe about a year ago, I've pretty much ignored Shiny for doing this kind of work. Even though I loved R programming, I preferred a different tool. I preferred to use Tableau. Now, for those of you who don't know, Tableau is another data viz dashboard building tool that you can use. You can often build something that looks a little bit like this. It's become very popular in the past few years, and something that's often asked for whenever you pursue a career in data and analytics. But it's not just Tableau. You also have Power BI. You have Domo. And these are often what people think about using for whenever they build some kind of user interface that contains data.

I often see people kind of ignore Shiny. And there's a lot of reasons for that. But I think it often comes back to this question of, why do I have to hand type a data science application? And what I mean by that is, if you look at the user interface for Tableau, it's much more visual. You see this bar graph here. And I was able to create it by just double clicking a dimension and double clicking a measure. And then you get a data visualization. There's a little bit more nuance that goes in the Tableau than that. But you're building a visual medium. And you get to see it visually as you build it. That's kind of the big appeal of this tool.

Shiny, on the other hand, where's my mouse? Shiny, on the other hand, you have to hand type everything. It is a tool that runs on top of R programming. So, you have to know R. And you have to hand type everything that you want it to do. This script that you see on this PowerPoint slide is actually the script that supports that app that I was just demonstrating earlier. And I can even fit it all on this PowerPoint slide. And that app's not that complicated. The actual app we delivered to the client had well over a thousand lines of code. Probably a couple thousand, if I remember correctly. And when you compare those other tools and what you're trying to build and you compare it to a process like this, where you have to hand type everything, it just seems tedious.

But it ultimately comes down to what Shiny's strengths are. That big tradeoff to hand typing everything brings many other strengths that allow us to deliver this project. One of those strengths is you can tell the app exactly what to do. You know, it's often said with those other tools, I've heard a few people say this now, is that they're really great at guessing what you want them to do. But with a tool like Shiny, you actually get to very clearly define the rules and behavior you want it to follow. And it comes back to the idea that you can hand type them. It also allows complex interactions and event tracking. That was very important to making sure that whenever the user interacted with that plot and changed the model inputs, it was actually the event tracking that allowed that process to occur.

This one's a little bit more obvious. It allows easier ML model integration. We were building a machine learning model for our manufacturing client. And we built it in R. And Shiny runs on R. So it's a lot easier to have that model integrate much more seamlessly in a Shiny app than it is for those other tools. This is a big one. This one often gets forgot when I think we talk about things like this. It's the ability to create data within the app. Those other tools are more reporting. They pull data from a database or a data set and then they report on them. It's a lot harder to manipulate and change data within the app or write to a database from those tools. But Shiny, on the other hand, it can write data to a database. But in this particular instance, the big appeal to Shiny for delivering this project was we're basically creating data whenever the end user moves those plot points. It's creating data that's going to feed into an algorithm as model inputs. That's a very important feature that's often missing in these other tools.

Shiny for subject matter experts

And when you compare all these strengths and weaknesses of these tools, what I realized, especially while working on this project with these manufacturing, is that it really changes who this tool is meant to serve in an organization. I think it's about serving the subject matter experts or the more highly skilled workers. That's to me what Shiny app is about, not the business stakeholders.

What do I mean by that? When you're a data scientist, this is a very broad generalization. But broadly speaking, you have two stakeholders. You have a business stakeholder and you have a subject matter expert. A business stakeholder is often like your vice presidents, your directors, sometimes their clients. And what they're often needing when they contact someone like you to build a data science application is reporting. They want to measure performance over the past few months and make a decision to adjust their business strategy based on that. They want to see how well they're doing to know how they should proceed in the future. They often don't need modeling. They often need modeling, but it's outside the context of building an application for them. Usually if they want an application, it's for reporting.

The subject matter expert, on the other hand, they often don't need a data science application to make it easier to present data to people. They're often needing to solve a problem. And that problem very often incorporates machine learning. And I actually think it's this kind of stakeholder that's often underutilized. And it's because we don't learn enough about tools like Shiny to help them. When you build them an application, you're needing to build something very specific that's governed by the rules of that person's job. And it often needs to incorporate modeling. And that's what those plant workers were. They were basically subject matter experts who needed an application that could perform this.

And that's the big rule I hope you take away from this is it's what I learned while working with these manufacturers is that Shiny just simply does what those other tools can't do. It's about building an application for subject matter experts who need advanced functionality, especially with statistics.

Shiny just simply does what those other tools can't do. It's about building an application for subject matter experts who need advanced functionality, especially with statistics.

Technical features and code walkthrough

So what was it about Shiny though that allowed that? I talked about the broad strengths, the kind of broad strokes of what Shiny does and how it can help them. But what I mean here is what are the technical features that allowed that? Well, obviously you can hand type the rules. I already said that before, but I want to show you that on this little snippet of code you see here. You know how earlier I said the first input and the last input in that model needed to be zero and 70. Well, there's just two lines of code and doesn't matter what the end user does. It will revert it back to it now just because I wrote it on that script.

There's also the various R packages. And the cool thing about R packages, it's basically you're relying on an entire community of people who love R programming. The obvious package that we use for this was Shiny. That one's obvious. That was developed by RStudio. But there's also Shiny matrix. Even though it has the word Shiny in it, this package was not developed by the people that developed Shiny. It was actually developed by a different group. And they're the ones that built the functionality that allowed me to hand type those inputs we discussed earlier. They just foresaw a need by someone like myself in the future to have that functionality on a Shiny app and they just developed it. There was also Plotly. Plotly foresaw a need for someone like myself to build interactive visualizations within Shiny. So, they provided the functions needed to do that. That ability to drag and drop those plot points is because of the Plotly function.

Within Shiny, there's also this concept of reactivity. This is another key feature that made this app work. More specifically, we used a combination of something called reactive list, reactive functions, and event observations. These three taken together made it possible for us to see that the end user was moving those individual model inputs and then reacting and rewriting the new data to serve as the model inputs later.

I can actually show you a little bit more of what I mean by that.

So, if you see here, we have the app that I showed you earlier. And let me think of the best way to do this. All right. So, now we can go to the actual app script. That's what this is. It's app.r. What you see here was generated by the code here. And for those who don't know, there's a few components to a Shiny app. You have your UI object. This is like the skeleton of the application. This determines where this table and this table go and also determines why you can toggle back and forth between these two input methods. Then there's the server object. This is where most of the actual coding and logic goes to support the functionality. It's where we actually generate the plot. If you look here, we have a render plotly function. And within that, we actually have the actual plotly function itself, which produces this plot.

Now, UI and server, those are the two common, I guess you would call them objects. But there's also global objects. And what you see up here is this matrix, which are the default values used. So, whenever we open this application, we actually see these original values here. And no matter what we do, those original values are going to stay the same because it matches what is in this default matrix identified in the global settings.

Now, normally, if we were making a shiny app that didn't require this interaction like we do, we could actually call upon that static data set in the global environment and pull it directly into the plotly one. And we would see those plot points just fine as it is. But because we want to give the ability for the end user to move those plot points and update a data set that feeds into the algorithm, we had to do a little bit more steps. And that's where this reactive values list comes in.

Now, pay close attention to something here. If you look right here, it says 39 and 0.67. And over here in the reactive values, it says 39 and 0.67. When I move this plot point, I'm going to move it to around 50 and 1. It stays the same in the original values, but it changes in the reactive values. That's because if we're going to do these kind of interactions, we have to both read reactive values and write to reactive values to make it work.

And let me give you a broad overview of where that's at in the code. So, right above our render plotly function right here, we have a reactive values list. I just call it RV. And I pulled the values for time and speed directly from that default matrix up above. That's why when you first open this app, the original values and the reactive values are the same. Next, we within let's see, within the render plotly function, we map those reactive values to the circles. And we also produce lines between them. In addition, we configure the plotly function to say we want the ability to do interactions with it. We want to be able to change the position of the shapes that are on there. And that's what those circles are. They're technically shapes.

We also label this plotly function with the ID speed S. This is very important in the event tracking. So, all that data you see in here on this plot is not actually these original values. They're the reactive values that have been copied from the original values.

Further down below, we have the observe event function. What this does is I very specifically told it to listen and keep an eye out on the end user on what they're doing. And if they happen to move a plotly point like they do, and that plot graph has the source of speed S, it's going to proceed with the script within that function. Right here, I won't walk you through these line by line, but basically what this does is it extracts the new coordinates. So, if I move this to 60 and 0.8, the new coordinates are 50 or close to 60 and 0.8. Those are the new coordinates. And it extracts those from the event data. It enforces the rules on top of them, which you see here, that 0 and 70. And it just rewrites it back to the reactive values list above.

So, it's basically becoming a circle. If I move this, it took the reactive values, gave it a new coordinates, and then it updated it back to the reactive value list. Same thing if I tried to move this. It takes the new values, makes sure it follows the rules. If it doesn't, it moves it back and then updates the reactive values list. The shiny matrix, that's what allows this right here where we can hand type the inputs. It normally wouldn't need to be put inside an observe event function the way we do. This functionality actually works pretty good on its own that you don't have to do that. But because we had to make sure it follows the same rules as the plotly graph and also because we had to make sure that we're syncing up these two input methods where if you change one on one, it needs to reflect on the other, we also had to pull it into an observe event function and apply those rules. But it's ultimately the same principles you're seeing there.

But that's where did my PowerPoint slide go? It took me all the way back to the beginning. Bear with me a moment. Sorry about that.

But yeah, that's ultimately how the app works. It uses a combination of packages that were developed by the community, the ability of us to hand type the rules and the reactivity concept all combined to allow us to deliver an application to the manufacturing plant workers and achieve the goal of democratizing those machine learning algorithms. And those plant workers are still using it to this day and they made immediate use about it. And from what I've been told by our client, they're very happy with it. But that's pretty much all I got for the presentation today.

If we have any questions, I'm happy to take those now.

Q&A

Awesome. Thank you so much, Taylor. I feel like the thing we miss with virtual is the actual like clapping after presentation. Thank you so much. I'm just a reminder to everyone that you can use the Slido link in the Zoom chat to ask any questions you can ask anonymously as well. And then just a reminder, if you do want to ask a question live, we are recording this session, so it will be shared up to YouTube. So I just want to make sure to point that out again.

But I see a few questions that have come through already, Taylor. And the first one is from Javier asked the editable table on the Shiny app. This was from the beginning of the presentation. Was this developed with a DT package or stock Shiny?

You're asking about this table right here, the editable one. This is actually from a package called Shiny Matrix. It's the one that allows you to just type in and edit things as you need them to. And it actually works pretty good on its own. You can download the package and just put it into the UI component. And if you don't really need to enforce rules on it, actually, you can just input it like that. And it seems to work pretty well.

There's another question that came in that is, how long did this development take prior to releasing it to the client?

Oh, I love that question. I actually don't quite remember. So the good news is we were able to divide up the work a little bit. So a colleague of mine named Pablo Lopez did most of the model building. And, you know, usually I'm not like a big fan of divvying up work within a project. I like to try to do most of it myself. But it was actually a very good thing that we did that because the modeling building aspect required a lot more study of how the manufacturing process worked and how to transform those time series like inputs into something the model could read. The part that I did probably took, if we added up all the hours, maybe 160. I don't think it would take that long if I were doing it again today. The reason it did take that long was I was having to read up on a lot of this functionality as I did it. I didn't know how to make a plot move like that and the way it did. I didn't even know if that was actually possible within Shiny. It was actually this project that demonstrated that value to me. I had to read a lot of Stack Overflow comments and read up on other blog posts and resources out on the internet. And so with all that research time and trying to build many proof of concepts along the way, it took me about maybe 140 to 160 hours, I would estimate.

Christian, I see you asked a question around ShinyMatrix. You said, does ShinyMatrix allow for copy and pasting multiple cells at a time or is it single cell input? Well, I think it is just single cell input, but they actually have a lot of little settings that can allow you to do more complicated things. So for example, there's a setting that allows you to, as you fill out the last row, it'll actually add a new row if you want to add a new one. As far as copying, it doesn't look like that's on this version, but they may on their documentation have information on how to do a large copy and paste like that.

Hi, this is Prabha. I asked how long it took question. I have a follow-up question to Taylor. So you said it takes 140, 150 hours, but from a calendar time point of view, I'm assuming that means it took maybe two, three months to deliver something to your client from the start. Is that a fair assumption? Yeah, I would say so. Again, if I didn't have other projects, yeah, it took about two to three months. Again, if I didn't have other projects going at the same time and I didn't have to research most of these functionality requests, it probably would have been faster, but they were pretty patient with that. They actually had that expectation to take about two to three months.

Actually, the main part of my question is, were they happy with what they got for waiting for two, three months? Yes, very much so. The reason we were able to keep them happy is we actually spoke with them every week and we were able to show them our progress. So we didn't like go away and they didn't hear from us for three months and then we showed it. We were on a weekly basis, we actually gave them updates of where we were in the functionality and we would explain the limitations we currently faced with it and that gave them a lot more confidence that we would meet the deadline. Actually, also too, we're actually still working on this application. We're doing a version two now where we're actually adding on top of the original one with additional models and other types of outputs.

There's an anonymous question that came through. Any recommendation on CI, CD tools or processes for a Shiny project? Not that I can think of at this time. If anyone else, also we can open this up, we'll pretend we're like in a real room together. If anyone else has feedback on that as well, feel free to jump in.

Oh, I actually just see another question come through. How do you deliver this product to the client as an R package website containing the Shiny app or a set code in a zip file? Well, there's a few layers to that question. So the actual plant workers open it up on RStudio Connect. That is a tool developed by RStudio that allows you to deploy these applications and the end user can log into that interface and select whatever app that they want to see. Delivering the app to them was actually a little bit more complicated because as I said, they're a defense contractor and they have a lot more rules in place for connecting systems together. So we had the data sets to build the models on our side and we were able to do that all on our own computers, but we actually had to send it to them as a zip file for them to deploy themselves. So it was a little bit of a tedious process because of those secrecy restrictions, but ultimately it winds up in RStudio Connect, which is a great tool by the way.

I see Jose just asked integration between Shiny and using, sorry, using R and Shiny and Python using reticulate package. Does this give new possibilities to modeling? Do you have any hints on this? That's a good question. I'll be honest. I've only done it from kind of like an academic practice scenario with using the reticulate package. And that was a few months ago. And I don't even remember the exact steps that I used to do it. So I'm probably not the best person to ask about using incorporating Python models with R models. For this particular project, we ultimately went with the R models, which are pretty easy to reference within a Shiny app.

Although maybe you could describe that your partner Pablo is more a Python guy. How did he have to deal with it? Yeah, he, my colleague Pablo, he really wanted to use Python for this application. And the challenge we ran into is there was a subject matter expert who was also a consultant on the client side. And he was very much an R guy. And he, he asked us specifically to use R whenever we were doing it and giving updates on performance. So we almost did actually use Python for the modeling building and or incorporation just because that's what the machine learning engineer on the project knew. But just for other kind of more practical reasons, we switched it over to R before delivering the project.

Sean just asked, did you use tidy models for the modeling? No, as I truth be told, I don't remember the actual package that my colleague used. But for the modeling that I did, I've used the carrot package. I do want to learn the tidy models package, though, that one's very exciting. Maybe it will be a little bit more straightforward to use if I finally get the time to investigate it.

What is your thought process on troubleshooting or building apps with reactive values and functions? Oh, I actually like this question. If anybody can think of an easier way to do it, I would love to hear it. But what I do, it's very much the same process you see on here. So this how-to article, it's going to walk you through all the steps. But I often tell you to keep an eye on these three tables you see here that I just went ahead and provided. So as I'm troubleshooting it, I actually have raw data table outputs over here to make sure that the data is doing what I want it to do. That's what allows me to know that the reactive values list is updating in the way that I want it to. I also built, it's not on the demo app that you're going to see on that how-to article, but I also had other tables like this to watch what was happening with the event data, the new coordinates that I was extracting. That made it a lot easier for me to make sure the right steps were being taken at the right time as I was developing the app. And as you write it, I would just hit run app or refresh app, and then I could see what it was doing after I changed the code. That's a great question though. If anyone has an easier way of doing that kind of work, I'd be happy to hear it because I like to see what happens to the data as I do it.

Javier, you go ahead. Just to chime in, at least on my end, I have kind of a standalone RMD or .R script that kind of pairs up against all my Shiny apps so that I can actually see what's happening much easier. I think there are some tools out there for kind of live troubleshooting or being able to see your reactive output, but I've found that those have limitations when you start using modules or trying to communicate or pass data between modules. So yeah, I just have like a standalone R script where I try to run these things on.

That's interesting. Did you say the R script connects directly to the Shiny app or is it just... No, no, it doesn't. It's just my way of being able to prototype sort of an engineering pipeline that then I'll transfer over to Shiny. I mean, that's one area where I still struggle is just troubleshooting, you know, anything that has to do with the reactivity or like reactive values or reactive polling. Like there are things that are still sort of, you know, tricky because you can't see and the errors are often very limited, the error messages.

Yeah. I actually kind of like what you're talking about and that was another thing we did as we were building this. And in hindsight, if I were starting this project again, I would have made more heavier use of modules to do this because we're practically doing that already and not with the actual modules, but following a similar process where I'd often build smaller proof of concept applications where I would just zero in on one unique aspect of the functionality they're wanting. So the actual drag and drop plots, when I was initially building that, I had only, I was just making an application just with that on it and kept practicing with it so that I could review my code and make the right updates at the right time.

And the one thing that I learned from that process that if I were doing that again, I probably would have made a heavier investment in learning how to use modules to pull it together in the end because I was already building it one small piece at a time. It would have been nice to just be able to import that as a module later on rather than copying and pasting. But that's a lesson I learned kind of late in the production process, so couldn't cleanly go back and fix it.

What do you mean by modules? That's a great question. This is something that I'm still learning myself, but modules allow you to break a Shiny app into smaller components and reuse those components across Shiny apps. Someone else may have more experience with me, but that's how I would think of a module. It allows building it piece by piece and then pulling it together at the end.

I totally agree with that. Modules to me are just more robust functions that when used with Shiny is coined the term Shiny modules, but you can use it for individual plots. You could use it for entire tab items or menu items to kind of iterate through different subsets of your data. There's a lot of different ways in which you could utilize modules.

So if you see this blog post here, this is actually the one I wrote. For those of you who want to replicate the functionality you saw here today, this will take you step by step. I'll put it on the chat box now. This is the more in-depth technical tutorial for what we have here today.

There's quite a few questions around how you deployed this, and I know you said that you've used RStudio Connect, but specifically for a client, is it on their internet or is it on cloud services like AWS? Wherever they installed, I actually don't know the answer to that for that particular client. I know for us, as we were building it internally, we used RStudio Connect server, and for us, that's on our own Linux host that we manage ourselves.

This is what RStudio Connect looks like. For those who don't know, you can deploy applications and R Markdown files and even schedule jobs in it. The way you would deploy it, excluding how we got that over to our client, we just sent them the script in an email. That's literally all we did was we saved the scripts and sent an email and said, this is how you should structure your file directory, but hypothetically, if we had access to their RStudio system, we would have just published it by clicking this button, and then it would go to the...

This is what RStudio Connect looks like. This is our own version that we use internally. It exists on a Linux server. I think ours is Ubuntu, and right here, this is where we developed the app in RStudio Pro. Now, the way we transfer this to the client for them to deploy, we just sent them the R scripts that supported the app, and we just said, make sure it follows this file directory. We also had to provide some model files, which are called .rds files, and just say, make sure you place it in this directory in relation to this directory, and you can deploy it, and it should work.

Going back to a few of the questions on troubleshooting Shiny, I see people have shared a few things in the chat as well, and Jake said the browser function can be extremely useful, and I see Paul, you just asked, did you use React Log at all to troubleshoot? No, actually, no, I think the person who was quality checking my app for me used React Log, but I didn't use it personally. I'll have to actually check that out and see if it's useful for doing what I wanted to do.

Going back over to the slide over a second, and I see Prasanna asked, if given a free hand, would you use Shiny and R or Dash and Python for such applications? Could you tell us some of the reasons for your preference? Oh, I really like this question. Keep in mind, I've only ever done anything with Python more from an administrator perspective, so as part of my team, my responsibility is I build Shiny, but also help administer RStudio Workbench. Now, within RStudio Workbench, you can actually build Dash apps, you can use Python, and you can use Reticulate to combine the two, but just from my experience, I don't actually know much about Python programming. I'm an R guy, and so that's what my main tool is, but I've had a lot of trouble from an administrator perspective in managing Python versions, making sure that they're using the right package repo, and I like to think I'm a very organized person that I'd be very good at that, but it always feels like there's all these little nuanced rules to Python management from an administrator perspective at an enterprise level that seem to conspire to prevent it from being a smooth process.

That may have to do with my own limitations of experience using Python, but for that reason, I like R better. It just seems easier to manage the package, easier to manage the Python version. Usually, even though there's lots of CRAN repo sources to download packages across the internet, they all basically serve in the same way, so you don't have to worry about downloading a package from Anaconda or from Pip or wherever else it comes from. You just download it from CRAN, and it seems to work. So, for all those reasons I described, my background is in R. From an administrator perspective, I have a lot of trouble managing Python in an effective way at an enterprise level. For those two reasons, I would always probably go with R Shiny. One day, I may change that tune. Our clients often ask for both Shiny and Dash app development, and I may have to buckle down and learn how to use Python and Dash, so maybe you can ask me that again in a couple of years, and I can give a real answer to that, but as of right now, I don't think I have enough experience to say one's better than the other, but I would prefer Shiny myself.

I was wondering, like, if somebody just wants to test out an RStudio Connect and see if they can just share with, like, just their friends and just test out just a production, if that is possible with, like, just a free version of RStudio Connect or, like, if that's possible. That's a very good question. I actually don't know enough about the how to trial RStudio products to answer that. That might be something the RStudio team can answer.

I could answer that. So, anyone can feel free to reach out to me directly, and I could connect you with the right person on our team, but yes, you can definitely try it out for free. You can email me at Rachel, R-A-C-H-A-E-L at RStudio.com, or if you just want to go directly over to sales, it's just sales at RStudio.com, and so they can actually set you up with a hosted evaluation too, so you can just get in and start playing around with it in, like, 10 minutes or so.

Definitely, and Paul, I see you're, and Tony also advocating for Shiny Apps IO is great as well, so if you're just starting to use Shiny, you can create a free account on there as well and publish your apps there, and then there's some basic tiers where you could add additional functionality as well.

Well, I wanted to add that, that's why I wanted to ask, Taylor, that you can probably use it if you're delivering these tools to external clients. You could create an account and deliver the tool to them, and then they would have their own personal link to demo your tool, where you push it out there and they can play with it, and that might facilitate a lot, you know, quicker feedback, right? I didn't know you guys had considered that, right, because it's external, but you push from the same button than you have for your normal connect.

Yeah, so actually, I have a few things to add to that. Yeah, like, with our existing RStudio Connect server, we probably could have generated them a username and password so that they could have logged in and viewed it from their systems. There was a security component that prevented us from connecting directly to their version of it, though. They have a lot of firewall restrictions, and yeah, just for security reasons, like, we didn't even actually get access to a virtual interface until this last week with them to actually log in as a user over there, so that's something we