Tom Mock | RStudio Connect in Production
https://rstudio.com/resources/webinars/rstudio-connect-in-production/ In part 2 of this 3 part series, Tom covers: Communicating results can be the most challenging part of Data Science: many insights never leave the laptops where they are discovered. In this webinar, we will show you how to use RStudio Connect to deploy your results in a production environment. You’ll learn how to automate publishing, schedule updates, and provide consumers with self-service access to your work. RStudio Connect is a revolutionary new way to host executable Data Science content. About Tom: Thomas is involved in the local and global data science community, serving as Outreach Coordinator for the Dallas R User Group, as a mentor for the R for Data Science Online Learning Community, as co-founder of #TidyTuesday, attending various Data Science and R-related conferences/meetups, and participated in Startup Weekend Fort Worth as a data scientist/entrepreneur
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Alright, so we'll get into it. Thank you so much for the introduction there, Rob. As you mentioned, I work on the customer success team here at RStudio. The basic idea is that I work with our professional customers to best use our professional products as well as open source packages in their specific environment. So I spend a lot of time thinking about kind of integrating open source with professional products, you know, using data science at scale in production, kind of in your own environment. And RStudio Connect is really one of the key players, at least of ours in that field of getting your data science products kind of off your laptop into production and ready for consumption in your organization.
So quick overview of today's agenda, I'll give you an overview of Connect, an overview of how our markdown plays together with Connect, and then do a quick demo of some of the examples I'm showing today. There's a lot of material here that we've kind of already covered with other topics. So specifically, I'll be focusing on our markdown. But if you're just interested in using kind of RStudio products in production, there's actually a webinar on that. There's model management, Shiny in production, as well as RStudio Team Quick Start, where you can actually try out Connect without installing anything. So maybe you think this is interesting, want to see what it looks like in your own environment, try it out there. And lastly, the solutions.rstudio.com website will be hosting a lot of the examples I used today.
What is RStudio Connect?
So again, RStudio Connect, kind of what it is, is a content hub and execution engine for all your data products. So this could be things like web apps, machine learning models as RESTful APIs, dashboards, reports, automatic emails or custom emails, tables and visualizations. Basically, anything you're already creating in R, it makes it where you can take those insights and leverage them a little bit faster. So you can share it widely, share it securely, just get it off your local environment and put it out there for your organization to actually use.
And importantly, RStudio Connect is fully interoperable. So it will play with any of the data products you can make in R. And additionally, it can communicate with things like R and Python or R and Spark, JavaScript, TensorFlow, SQL. All these things can be integrated into the data products you're creating. So you have a nice platform to push out all of these things that you're making.
The basic idea of what it would look like in your environment, and this is just a very simple example, is you create something locally, maybe on your desktop in RStudio IDE or RStudio Server or RStudio Server Pro. You then have push button deployment to push whatever you create, say a Shiny application or R Markdown document on to Connect. Connect will then host it. It will provide all the scaling and security you need. It can connect to your file share system. It can connect to your databases. And ultimately, your end users will just access that content via their own web browser. So they really just kind of see it as a website. But in reality, it's a hosted on premise solution for your group.
What does production mean?
So what does production mean to me? I'll steal a quote from Joe Chang that he gave at the most recent RStudio Conf. Production means a software environment that is used and then relied upon by real users with real consequences if things go wrong. So specifically, you know, this doesn't talk about how big the environment is. It doesn't talk about how widely it's used, just something the business relies upon, something the business is using to either make decisions or to gain insight about some data science product. That's really the ultimate goal of data science is to inform a business decision to provide value of some type for the organization or for the individual.
Production means a software environment that is used and then relied upon by real users with real consequences if things go wrong.
So beyond kind of that basic idea, in my mind, there's some other production needs. So things like scaling and execution, you know, you want to have it be able to work for your entire organization if you wanted to, as opposed to just locally on your own laptop. You want to have security and access control. So you don't want to just put it out there for everyone on the Internet to access. And even within your own group, maybe you want to have only execs see these specific materials or only your data science groups see other material. You also want to have logging and visibility into the applications you've already pushed out there or the things you're using in production, as well as logging about the performance or when they've been updated or changes that have been made.
And as Garrett covered in the last webinar, reproducibility is also a huge component. And with a code-based solution like R, you're really focusing on being able to reproduce both that environment as well as the actual code that you've used to create your asset. And lastly, something I think is really important is the sharing and collaboration idea. So sharing in terms of you're creating something you worked and spent a lot of time on creating a model or evaluating a model, making some type of prediction, you know, doing some core data science tasks. And then ultimately, you have to inform somebody or share that with somebody and have a useful discussion with them.
Ultimately, the kind of the idea here is production doesn't have to be as scary as you want it as it kind of always comes out to be. So, yes, there are some environments that are extremely locked down, extremely complex. They're serving thousands and thousands of users. And, you know, just a lot goes into it from a DevOps standpoint. There's other people who really just want to take some type of R based product and put it out there for five to ten people. And the kind of the concept here is that I have customers on both ends of the spectrum, you know, very small groups serving other small groups and other people who are serving, you know, hundreds or thousands of individuals within their organization.
What Connect provides
So in terms of what Connect provides in this concept is kind of hitting on the same points that I said before. So scaling, execution, high availability. Basically, you can take your Shiny application, your R Markdown and scale it out to your organization. Additionally, because Connect can actually execute R code, it can actually rerun your R scripts or R Markdown documents or your Shiny applications for new people. As far as the high availability concept, you can have multiple Connect servers kind of in a cluster. So if part of your server were to go down, you have another one ready to go. Or if you just want to share the load across multiple servers, that's also possible.
Additionally, you have full security access control and visibility. So you can bring your own LDAP, Active Directory, SAML security to authenticate users. You have access control. So at the application or server level, you can specify who can see what as well as have applications that are only for testing or only for production use. And lastly, you have full visibility in terms of you can see what's been published there and you can kind of understand what's being used in your organization.
Additionally, from the reproducibility and logging standpoint, I'll cover this a little bit later, but you have these kind of sandbox environments on Connect where you publish something, it tracks the R environment, it tracks all the different packages that are being used. So you have this kind of metadata about the assets you're creating. You also have logging about both use of it and updates to those assets. And lastly, you have full sharing and collaboration.
So yes, you can now take an R Markdown document and just publish the finished document out onto Connect and then people can access it via web browser, which is a huge win for a lot of people. But additionally, it opens up as an execution engine where those people who may not know how to code can actually re-execute those R Markdown documents or Shiny applications to create something they want to see without ever having to go and bother the data scientist directly. And lastly, you have the collaboration and discoverability. You can actually search around on Connect and find things of interest. Ultimately, Connect's getting your data products off your laptop and ready for consumption in your environment.
Security and reproducibility
Again, when I talk about security, you have kind of three major levels of security that I like to focus on. So your server level, just authenticated users accessing your content so you can bring your own kind of security. A lot of people are familiar with Active Directory, LDAP, SAML. You also have app level so you can restrict user access to your applications, whether they're Shiny or Markdown. And lastly, you can even have data level access to specific things even within an application. So all these different tiers of security and access that you like to see in your production environment.
As far as the reproducibility, I hit on this a little bit earlier, but the big idea here is that you really don't want to create something, put it out there, and then all of a sudden not have governance or understanding of how you created it. So you don't want to lose the code. You don't want to lose the information about which package version you were on or which version of R you were on or what were even the system dependencies that you were using there. So importantly, the way that Connect works is you create an asset locally. So maybe it's on a server through RStudio Server or on the desktop IDE. So you write an application, you create an R Markdown document, whatever you're doing, you actually bundle that together when you click publish. So this is all done automatically. You just click publish, Connect will bundle all that information together.
So you have the source code, you have the metadata around the specific dependencies that's pushed out to Connect. Connect then unpacks the bundle with this Packrat bundle and it actually reinstalls the specific dependencies at the exact package version you're using. So the same version of R, the same version of the exact packages you're using. So you have this kind of sandboxed environment of exactly what you want it to be. Importantly, each data product has its own R environment. So this prevents breaking existing deployed content. You can have multiple versions of R basically running across your different assets, multiple different package versions running across your different assets if you wanted to.
Deployment options
So when people talk about pushing to prod, the joke is always don't push anything out on Friday afternoon. You don't want to just put something out there into the world and then disappear for the weekend. So people will think very differently about how they're publishing or how they're deploying assets into their production environment. For a group just starting out, you know, they're ecstatic and super excited about just doing push button deployment, you know, just being able to create something locally and basically in a few seconds, publish it out and have it ready to go and shared across your entire group. Other groups are very much more about the governance and the DevOps side where they want to have kind of man in the middle or woman in the middle, just someone there who is making a decision about is this ready to go to productions. Maybe that means code review or putting it into Git or continuous integration.
The first option would be just push button deployment, which is the default. So within the IDE, you can actually click this little blue button and it will publish things on to Connect. At that point, you could still restrict access. So maybe you want to push it out, play around with it on Connect and only you can access it at this point. And then after the fact, you could say, OK, well, this is running well. I'll allow access to the rest of our audience and kind of open it up to the rest of the group to kind of use the data product.
Alternatively, you could put things out through Git. So you could have a Git back deployment where you're not going to push button deployment anymore, but rather you're actually pushing something out in a version control through Git and then Connect is kind of calling out to Git and installing it directly from there.
On the alternative side, rather than having kind of this one step process, you could have a testing and then a production environment or what we like to call kind of a staging and then a production environment. So in this case, you actually publish your asset initially into kind of a sandbox staging or testing environment. So a different version of Connect and only your kind of DevOps or data science team is accessing at this point or just dogfooding it, testing it, making sure things are rock solid. Once it's gone through that stage, you can then redeploy it onto your production environment and let the rest of your consumers use it now that you know that it's working properly.
And lastly, another one would be continuous integration. So still doing your sandboxing, your testing approval, and then the request is actually sent to merge into your version control. It goes through code review. It's pushed out to the master branch and then a continuous integration server will actually publish this production itself. So something like Jenkins will go out there, pull the code that's been updated and then republish it onto Connect.
R Markdown in production
Again, I mentioned I'd be covering a lot of R Markdown. A lot of people are familiar with R Markdown, kind of on their local environment, writing reports, maybe creating a blog or even creating small websites. And the idea being that you can create all these things, but then where are you going to put them? And Connect can be that place. Obviously, you can also host things like Shiny applications, which has been covered in other webinars, or even putting a model into production as a RESTful API, which has also been covered in another link that I shared in this webinar.
But the idea here is that you have a spectrum of interactivity with your documents. And Garrett covered this really well last week, so I stole this slide from him. Kind of the idea of you have this spectrum of more interactivity. So a local R&D that you're working in interactively, and then you need it once. And so it's not really interactive. Maybe you have an R&D with parameters. So now you can create many reports from a single master report. You could add an HTML widget for front end interactivity that doesn't require server backend and gives you all of this kind of fancy Shiny-esque environment or kind of interactivity, but you don't have to have it hosted with a Shiny backend. And then you could fully put a Shiny component onto it.
The idea being that I'm going to focus kind of on the first three points here. Basic R Markdowns, R Markdowns with parameters, and R Markdowns with HTML widgets, specifically on RStudio Connect. And this is why I like to think about it as R Markdown in production. Not just using R Markdown as your basic reporting just for yourself, but thinking of R Markdown as like a key player in your data science environment and in your data science kind of production environment, where you're using R Markdown as a way to create repeated jobs or reports or automated emails, all these different things that can provide value for your company that you may not be using today.
So the basic idea of an R Markdown report, again, I'll just cover it briefly in case you missed last week's webinar. It's an open source R package that produces high production quality documents by integrating pros with code and results. Basically, you can write, you can create code, and you can create outputs all within a single document. So this is really useful for data scientists who are already using R and they want to both create a report and share the report in a reproducible way. It can create all sorts of different output formats, everything from basic documents, PDF, journals, full blown Web pages, Word docs, other R Markdown formats.
Importantly, all these different output formats can actually be published and hosted on Connect. So you can actually publish the finished product as well as bundle the code and the finished product, where it can actually be re-executed on Connect without having to write additional code.
So with parameterized reports, kind of taking the next step from R Markdown, kind of the idea here is that you take a single R Markdown, write a function around it, and then you can loop through or use a map function from Purr to create multiple versions of this report. So this is just kind of a fake report I put together. The idea here is that you're rendering a specific R Markdown document. You're listing some parameters. So these parameters tell you that state and year for it will be generated kind of on the fly based on your inputs. And then you're creating this output file as an HTML output.
You can also use things like HTML widgets, which I mentioned before is front end interactivity. So those do not require a server back end. So you could publish our markdown document with, say, the leaflet package, which provides a JavaScript and HTML on the front end. We're able to interact and kind of get this kind of Google Maps, but it's really OpenStreetMap interactivity around maps. There's a ton of different HTML widgets and even things like crosstalk where you can have HTML widgets talk to each other on the same Web page.
And lastly, something of interest and something that I'm really excited about is the Blastula package, which is a way of creating beautiful HTML emails in R and in RMDs. So the basic idea is that you can write a basic script or almost like an R markdown-esque format here of what you want the email to say. It can then run this email based off of some R input and have an output of this beautiful HTML email that can then be pushed out through Connect automatically. So, yes, you could create a report that people can interact with. You could also have that same report kind of copy pasted into an email and sent to a specific person, even if they're not accessing Connect.
Live demo
And so these three things here are something I'm going to cover on the demo portion, which I'll get over to here in a second. And lastly, there is this link here where Kelly O'Brien actually put together an example of custom scheduled emails with Blastula and RStudio Connect. It's a great read through.
With this, I'd like to jump over into the demonstration point.
All right. So for most people, hopefully this is familiar in terms of this is the RStudio IDE. Importantly, I'm actually accessing this through my web browser. So this is RStudio Server Pro. You could technically use the desktop IDE and get the same kind of experience with publishing. So the idea here is that I create an application. If I want to publish it, I can publish it to Connect here. By just clicking this blue publish button, I take all the source code. It finds the data that is necessary to run this, bundles it all together and says, do you want to publish it? Now, I've actually published this already, so I would be updating an existing asset. But I would just click publish and it would push all that and reinstall the packages onto Colorado, which is our internal Connect server. But the idea here is that that's it. That's push button deployment. You know, one button press, you're ready to go and it's pushed out there.
So this application will just go through the Shiny app first. I publish it onto Connect. The basic landing page for Connect gets me here. So the immediate thing of interest is that you had your discoverability built in. I can see all the content I own. I could also filter back out and just look at all the server content, you know, going in and even searching for maybe I just want to look for PDFs. I could search for PDF documents and find things that have been in the PDF. I also have a full blown tagging system. So internally we do this around technologies, but you can imagine a world where in your environment you actually want to filter it out by specific teams or by specific assets.
Additionally, from an administrative side, you can see all the different people who have access to content. You can see the different roles, so publishers versus viewers, so people who can only consume content versus people who publish, all the way down to administrators who have additional privileges around, you know, changing assets that have already been published. I can even go in here and, you know, lock or edit the administrator roles for this person.
You also have visibility into the use of your applications or the use of your server. You can see how many people are actually on your server, how many connections are being used, how much RAM and CPU of your server is being used. You know, is it getting hit a lot or is it being used at a low level? You also have, you know, your audit logs. You can actually see all the different things that have happened, different events over time. So you have this visibility into things that are occurring on your server.
With that, we have about 15 minutes left. So I do want to get into the demo portion. The first idea here is I've taken my existing code. So this access to care hospital dashboard, which was created by Edgar, one of the solution engineers here at RStudio. And this has been published on the Connect. There's a couple of things going on here that I want to show you in terms of this is actually a Flex dashboard set up. So you'll have a Shiny runtime on top of that. So because it has a Shiny runtime, that means you can re-execute R code on the fly. So I can switch between states and it will re-execute R code and give me some type of new output. On the front end, I actually have an HTML widget. So this interactivity here doesn't require the server backend.
So I'm going to be using this example for the rest of my R markdown examples, but wanted to start with the Shiny example. Because this is Shiny, you have access to the Shiny runtime in terms of the server itself. So you can go in here and specify specific settings, or you just use the server defaults, about how to scale out this application or how performant you want to be. So maybe you want it to idle out and kind of close down pretty quickly, because once people stop using it, you want it to free up compute on your server.
So I mentioned a little bit about HTML widgets, and I want to show you this specific example that is kind of a hello world, more basic example of HTML widgets plus crosstalk. So in this case, there isn't a Shiny runtime. So there's no server on the back end. This is just the HTML front end. So in this case, I can actually filter and change my graph here without having to rerun our code. I publish this out, and the only thing that's being changed is HTML and JavaScript on the front end. So all this interactivity I have built in doesn't require a running Shiny example.
So going back to our access to care by state example, maybe you take that Shiny application and you're like, oh, well, I really just want to send out reports to each of the state governors and say like, hey, you know, your state is doing well or doing poorly and how many hospitals it has for user population. So you take that same R markdown based report, change the output to PDF and publish this on the Connect as well. So now it's hosted. It's got authenticated access. And only people who are allowed to see it can actually come in and access it. You still have the table. You still have a map because it's PDF. There's no interactivity. It's just a static document.
Importantly, if I go in here into the Connect portion, I can see that the access of who can actually edit this document. So who can change it? Only these four people. So Edgar actually push it out. And then the three collaborators. But I've made it where anyone can access or view this document without logging required. I could make this to where users specifically would have to log in or only to specific users or groups like, say, the administration team or the exec team, all the way down to just the collaborators and the owner of the document.
Additionally, because it's not a shiny application, there's no runtime, so there's no R code being executed continuously. But because it's an R markdown document, I could still schedule this output to occur at a specific time interval. So I could say, yes, I see this application or this report. I want it to run once a week for eternity. You know, every week it updates the data and creates a new report. So I want to see that here. I connect so I can schedule the report to occur every Wednesday like today. I'll run weekly on Wednesday and I want to publish an output. I can also send an email after the update. So not only does it publish it here on the Connect, it would actually send it to all the collaborators, all the viewers or or whoever you wanted to go out to.
Additionally, beyond just kind of the pure, I just want to see this report. There was a lot more states here in the shiny application besides just California. Because this is a parameterized R markdown, I can actually go in here on the left tab and change the parameters within Connect, rerun the report and regenerate the output. So I could change it to Texas, Colorado, wherever I wanted to be, rerun the report and it will regenerate that.
I'll go into the HTML, which is an example to kind of show that because it's a little more fun to have the interactivity. So PDF is great, but maybe we want to still have some interactivity. So now this is still an R markdown document. So there's no shiny runtime. But if I go in here, I can still get front end interactivity. So what is the user population there? How many hospitals are expected versus how many do they have? I have a data table down here in terms of I can actually click through and adjust this data table. I could sort by population alphabetically, number of hospitals, all of this interactivity that's built in here. And kind of I don't have to use computational resources around a shiny application.
Importantly, you have the same idea. You could still schedule this report to run. You can see I have it where it's running every Monday. It actually sends me an email every Monday so that I get this updated report. Additionally, you can save different versions. So I live in Texas. So maybe I want to always come back in here and see Texas. So I can actually save a personal report for myself.
And again, because it's parameterized, I can go in here and give it to someone who doesn't know how to code at all in R, but wants to see this report for Delaware. So they can actually come in here, run the report, Connect will execute the code, rerun the report, regenerate it, reknit it, all of this and put it back here into your viewport. And this person can then self-service, provide their own analytics or create their own reporting. So you can take your data science model or your data science product that you've created here, create a report around it, and then share that widely within your organization, including people who can code or people who cannot code.
So you can take your data science model or your data science product that you've created here, create a report around it, and then share that widely within your organization, including people who can code or people who cannot code.
Additionally, you can take kind of a similar Markdown report and get out to a Xaringan presentation. So same idea. You have a XY coordinate of your hospitals versus user population. You can look at the linear relationship between the two and then actually output the model around that. So maybe this would be more interesting for your data scientists as opposed to your executive team. But similarly, this is built purely from our Markdown report that's been generated out to a Xaringan HTML and JavaScript presentation. And it could still be scheduled to rerun or parameterized as needed.
Additionally, because Connect also allows for publishing from Jupyter Notebooks, you can take the same data, run similar ideas in terms you're looking at population versus county level and how many hospitals there are. And this is actually a Jupyter Notebook that's been published onto RStudio Connect. So maybe you have a lot of people working in R, maybe a lot of people working in R and in Python. Like this is primarily Python code. You could have Python integrated into our Markdown through Reticulate, or you could actually publish directly from your Jupyter Notebook onto Connect through the Jupyter plugin. So really making it a widely used tool, kind of regardless of the language you're putting into the table.
Moving a little bit beyond the concept of all these different reports, maybe doing some things that would be more along the lines of a little bit of data engineering or kind of more, less kind of interesting, but very necessary and useful ideas. So here we're doing an extract transform load or ETL script. This is run as an R Markdown document. It's running some R code, generating some type of output, creating some portfolio ideas around stock prices. And then it's actually writing this out to a table within our database. So the idea here is that you could take this ETL script as an R Markdown document. And rather than having to run a cron job or manually do all this stuff, you just have it automatically update once a week, once a day, every hour, once a month, however you want to schedule it, you could have this ETL job rerun and prepare your data for you. So first thing in the morning, it's ready to go and you don't have to go in and do this manually.
Additionally, kind of taking something still within the reporting space or the kind of R Markdown output, creating this report that's rich and you look at this and, you know, it's a useful report. It's got some front end interactivity. Again, no shiny here, but you have the ability to zoom in and drill down kind of at specific levels. Regardless of the content here, the idea is that this is all built from an R Markdown document. So, again, you can do your parameterization and specify different levels. You could have, you know, 10 different inputs or however many inputs you wanted to.
Additionally, this actually has a link to download the report as an Excel file. So people are still going to use spreadsheet software kind of within an organization. It's going to happen. But at least at this point, you've generated it programmatically. So you have full visibility into you've created a report with code. So you know exactly why and how it was created. And now you have a file that can be shared widely that you have kind of visibility into.
Additionally, and again, kind of hitting on the same note, I could send an email about this automatically or I could send it to myself manually. So kind of taking this idea of being able to share it widely within my organization, either in the inbox or on Connect.
So this same report is now in my inbox. So you can see that this is an HTML output. It's almost identical to the report on Connect. So this is just in my inbox. I sent myself last night. It has the same idea where you still have a graph that you could look at. You have a full rich text format table. You can go back to Connect and click on it and even paste in the Excel file here in your email. So rather than having doing this manual request and responding directly to ad hoc request, you're able to have this done either automatically or programmatically and send out these very rich emails.
Wrapping up
So hopefully that was interesting to you all. We're running out of time here with a couple of minutes left. So I'm just going to hit on a couple of the last slides and points. A lot of these examples came from the solutions that are studio dot com Web site, specifically if you go here to the by industry health care access to care portion. But really importantly, this has a lot of our best practices for using both our studio, professional products and generally a lot of how we're thinking about using R and R plus Python kind of in your environment to do data science at scale.
Lastly, if you are interested in kind of learning more about Connect, you can go here to the studio dot com slash product slash connect. There's a free 45 day evaluation where you can try it on your own server or on the cloud, or you can download a pre-configured quick start where you just install a virtual machine and then run it on that.
I appreciate everyone joining me here for today. So the real core concept here is that Connect can help you get started or help you level up. So whether you're kind of just getting started in your long data science journey, you have a small team and you really just want to start having a more robust data science environment. Connect is ready for your team to start publishing things and creating assets out there for your team to actually have insights around. Alternatively, if you have a more robust data science environment, you're starting to use continuous integration. You want high availability scaling. You have hundreds or thousands of users. Connect is still ready to serve you. So across this entire spectrum, Connect is a ready product for you to help level up your data science environment.
And this is really hyped upon or harped upon here by Sean, who's the product manager here at RStudio. I see a lot of our users feel like imposters when production comes up. Lots of tools and lingos out there. But trust me, if you fit a model, the rest doesn't have to be hard. With RStudio Connect, you can take the hard work you've already done on your core data science work and take that and take it to the next level with R Markdown, or Shiny, or Plumber APIs, all publishing on the Connect.
But trust me, if you fit a model, the rest doesn't have to be hard. With RStudio Connect, you can take the hard work you've already done on your core data science work and take that and take it to the next level with R Markdown, or Shiny, or Plumber APIs, all publishing on the Connect.
With that, I'll leave you with these last few slides or links, which are the same links from the beginning. Basically, additional webinars for you to take a look at, specific to administrating RStudio as a whole, model management and putting models in production using RStudio Connect, and then Shiny in production, more about the principles, practices and tools by Joe Chang. Additionally, Kelly O'Brien will be giving the third webinar in this webinar series, and she'll be talking a little bit more about interactivity in production, including a bit of Shiny. Lastly, again, we do have 45 day free evaluation of pro products, so if you want to try something out or you can always book a call with us to talk about RStudio Connect through rstudio.youcanbookme. Thanks. With that, I will go back to questions.
Q&A
Looks like one here from Steve. When a regular R Markdown is on Connect, can the code be modified and run right there in the browser like a Jupyter Notebook? So the R Markdown itself is executed through parameters. So you would still be, if you wanted to work with it interactively, you'd be using it either in the IDE, so that could be through RStudio Server Pro or your desktop IDE. But really kind of the idea of Connect is that you publish both the finished product as well as the source code. So you can still run and update things through parameters, but you want to have kind of a static input there.
For small teams, are there pricing options that get you started other than 45 days free? So for kind of aiming at the academic as well as small businesses? Yes, we do have academic discounts as well as small business discounts, depending upon your revenue. So absolutely reach out to us via salesrstudio.com, and we're happy to generate kind of have a discussion around what you're looking for and work around kind of the budget you have.
And it looks like all the rest of the questions were answered, so I think we're good there. But I appreciate y'all's attention today and have a good rest of your week.
