Transcript#

This transcript was generated automatically and may contain errors.

Hey there, welcome to the Posit Data Science Hangout. I'm Libby Herron, and this is a recording of our weekly community call that happens every Thursday at 12 p.m. U.S. Eastern Time. If you are not joining us live, you miss out on the amazing chat that's going on. So find the link in the description where you can add our call to your calendar and come hang out with the most supportive, friendly, and funny data community you'll ever experience.

Can't wait to see you there. I am so excited to welcome our featured leader today. We're talking to Jason Frederick, Corporate Treasurer Interim at Texas Capitol. Jason, could you introduce yourself? Tell us a little bit about what you do and something that you like to do for fun.

Sure, happy to do so, Libby. No, thank you all for having me. I've been an off-and-on member here in the Hangout when I can join. I'm not a typical data science leader or someone you would think of that at a bank, specifically in the corporate treasurer role. And that role came to me just a few weeks ago as my boss, he went to become the CFO at Trustmark Bank. And so I needed to step into his role. And so hopefully it'll become permanent, but that's how these things happen in large organizations.

So I'm happy to serve as a corporate treasurer. Obviously, my primary function right now is managing the liquidity and interest rate risk and oversight of our investment portfolio here at the firm. So certainly not directly related to POSIT or data products. However, all of those functions require extensive analytics. And I have been a member in the data community for years and been building on that for many, many years.

Background and journey into R and Shiny

My background, I was electrical engineering and physics degree back in 2002 when I graduated from college. So we're already 24 years out. I know I don't look that old, but especially probably on camera, but that does date me. Back then, I mean, I was using MATLAB and R, of course, as an engineer. And R certainly wasn't as developed. I don't think RStudio was really developing packages at that point. So it was base R, which was kind of a mess, frankly. MATLAB and the commercial solutions were a lot easier to use from an engineering standpoint. But that was my introduction to Linux and into R. And I put it away for a while, went on to grad school eventually. And there we were using Stata and MATLAB more.

And then probably, as an economist with BBVA USA, I was using a specialized software called regression analysis for time series, something probably nobody's ever heard of here called RATS with a man in Illinois with Estima Software who basically wrote C functions to do all of this complex time series analysis. But that enabled me to do forecasting in simple ways and implement things like vector autoregressions and Bayesian vector autoregressions, all things heavy in the time series community. So fast forward a few years, I needed to build models for all of our balance sheet at a $80 billion bank where I was before here. We're roughly a $30 billion in asset size at this bank. But so it's a much larger bank. And I had a team, they were contractors that built out all of this modeling work in R. And I'm like, wait, what? Y'all used R for this? I can't believe it. And they had all these packages here from RStudio and others. And I'm like, I like this. I can work with this.

And so instead of RATS, I started to really embrace R. And about that time, 2015 or so, I remember Shiny coming online. And I just kind of, in the back of my head, I saw it. I felt it. And I said, you know what, I need to get to know Shiny. So I brought in an intern for the summer and I told the intern, I said, go figure it out, please. Go figure out how to use Shiny. And sure enough, he did throughout the summer and handed me back a nice project. And I'm like, all right, I can do this. So I grabbed this, quickly programmed it up. And I had a whole, using an Excel file upload, and I had our entire balance sheet on there and risks and opportunities that we were seeing in terms of growth in our income in our balance sheet to highlight for executive communication, which is primarily what we needed to do.

Because I have this theory, there's the three-click rule you probably heard in dashboards where you need to get to your result in three clicks or less. If you're designing dashboards for an executive, they need to spend, they're going to spend like 30 seconds on there or less. So when they go to that dashboard, they need to see what they need to see and they need to get off. And that's what's going to happen. And if it's too complicated or too much information that they're seeing, they're going to click away from it and never call you again. So you've got to communicate with that information, with targeted dashboards.

If you're designing dashboards for an executive, they need to spend, they're going to spend like 30 seconds on there or less. So when they go to that dashboard, they need to see what they need to see and they need to get off. So you've got to communicate with that information, with targeted dashboards.

Deploying Shiny apps: from a laptop IP to AWS to Posit Connect

So I went wild with Shiny. I got really excited about it. And I remember at the time, I didn't know how to serve though. I built these apps and didn't know how to serve them. So our internal network, I actually served them from the IP address of my, the internal IP address of my computer within the corporate network. And so I tell my boss, hey, go to 10.10.108.20, you know, port 52. And then you can see the dashboard, right? And they're like, what are you doing, Jason? I'm like, don't worry about it. Just go see it. Do you like it? And then they liked it. So I then turned around and said, I got to find a better solution.

So I went to engineering and I said, hey, can you guys, they were just getting into AWS back then. And I said, hey, can y'all give me an EC2 instance on the cloud? And I'm like, give it to me. I know Linux. I'll take care of it. Just give me this. Give me a nice Ubuntu instance. And like, fine, Jason, whatever. Here's an Ubuntu instance. And I took that and I actually took Louis Aslett. Some of you guys may have heard of him. He's a professor, but I've never met him. But he hosted Amazon machine images for Shiny in RStudio in the open source versions. And so I started with that image and I pushed it onto the EC2 instance. I built my own, but with instructions from a lot of the RStudio team. But this image was easier to just deploy quickly. So I got it deployed over there on the EC2 instance and learned a lot with it. And sure enough, I started being able to serve these applications through the cloud. And then I went to engineering and said, hey, can you give me a web domain address at the internal? And they're like, yeah, sure, Jason, whatever. All this was internal, right? Nothing public. The firewall was there to prevent all that. So then, yeah. So once I had that, I was gone. I was golden.

So I started serving all of these Shiny applications throughout the bank. And it really just ballooned over that time. And I remember at one point I went to a POSIT conference because I had this challenge. I had all of these different, well, I mean, we had 10 to 12 different categories as we think of in a bank's balance sheet. So we think of commercial loans, maybe equity, home equity loans. We think of auto loans. We might think of commercial real estate loans. Now on the deposit side, we have non-interest bearing deposits like your checking account. We have interest bearing deposits that we pay for. We have deposits we take in from public companies or public entities like municipalities. Those are called public deposits. We have just all different categories of deposits and loans. So I wanted to know each of those has their own dynamics. And I wanted a daily view, like a waterfall chart and understanding with graphics of how we're going to get what's going on in the portfolios, right? Because my job was to manage the balance sheet and provide different strategic insight around that.

So I said, all right, I go to this POSIT conference and somebody gave a presentation on Flex Dashboard with our Shiny and pre-rendered Flex Dashboards. And so I said, oh, that's how I can do this in the easiest way because I didn't want to write a bunch of nested Shiny code with each individual. I mean, it would have been faster, sure. But Flex Dashboard certainly has overhead. But I didn't care. The pre-rendering solved the render problem. And I was able to just build all these Markdown files, write one for each portfolio. And it just made my job so much easier to scale that deployment across the bank. And I had the whole balance sheet built out in a couple of months. And then I turned it all into a website.

You keep mentioning deploying things. And you said AWS. Were you still on AWS at this point or were you? No, it's all AWS. Everything was deployed on AWS with Shiny Server. Sorry. Deployed with Shiny Server. Oh, OK. Shiny Server. Shiny Server open source. Yeah, I should have clarified that.

So that was my background in Linux. Then I came to Texas Capital Bank and I said, we got to get an enterprise analytic platform stood up. And so I came to Posit and said, what solutions you got? By that time, we had Posit Teams. I really wanted Posit Connect because I didn't want to manage a Linux server anymore. Yeah. And that was the key. Right. And so we got Posit Teams. We ended up with Posit Workbench. We deployed Posit Workbench within SageMaker on our studio because the engineering team did not want to manage the infrastructure. So we used AWS's managed image for our studio and SageMaker. And then we built out Posit Connect. We built the image and deployed it onto an internal ECS cluster on AWS. Right. So now that's where we are today. And my team and then other teams that we brought in. So mainly in finance, my team, but also in the risk analytics team. And I have Carlos I've brought in today. They have embraced the Posit Connect environment for deployment. OK. And deployed tons of applications over there that we built internally to enhance the operation of the bank. And I asked Carlos to join, too, because he's closer to the coding than I am in now. And he's recently been expanding in the use of AI through Copilot to enhance his output. So he'll be a good source, too. So let me pause there a minute. That was a lot of information and history, but I think it's relevant. My job now is to be an advocate for enterprise data analytics and an advocate for Posit inside of a bank where I'm at.

Interesting problems in banking data science

OK, that was so much. Thank you so much. That was a lot of background. I think that helped give us some context around questions that we can ask. It sounds like you've built a career on Shiny, which is amazing and wild to me. And when you said I went wild with Shiny, I'm like, that's all of us when we discovered Shiny. We discovered Shiny and Leaflet at the same time. And I remember just like, well, now everything could be Shiny and Leaflet. But I know how difficult it is doing all of that stuff manually. So I'm glad that you got Kinect eventually so you could have some push button deployment, which is a lifesaver.

Hi, my name is Noor. I am, I am, I guess, a data scientist, I guess, but I work in the biological domain. But I know I come from math and stats, so lots of things are applicable in other domains. So what do you think are interesting problems are you think that are specific to banking or finance related data science?

Yeah, there are so many that that as you know, the challenge in banking for years, it's a heavily regulated industry. And many banks are been laggards in the data analytics space. But they are catching up and building enterprise data warehouses. We are using Snowflake in the background, which is state of the art. And Snowflake has has been a great repository for that. But there are many use cases such as fraud analytics that not only is being enhanced by AI, but traditional ML machine learning type approaches. I am focused on balance sheet analytics. So we do things like deposit studies, which are interesting. So we need to be able to value our deposit base and see the duration of those deposits. So that is generally account level information. And we're looking at decay rates at the portfolio level. So we need to be able to model changes there. We are heavily involved in different types of risk and market risk that we need to have insight on and analytics on. So that that's also an avenue on that side.

We typically for interest rate risk measurement, which is effectively if you think about it, interest rate risk at a bank, it refers to how rates move, and the repricing of our assets, which are our loans, and our liabilities, which are deposits, and those things reprice at different schedules, creating risk that to our income stream. And that's what interest rate risk at a high level refers to. And so we typically use specialized software to manage that. But we do analytics on forecasting. We're always looking at where we think with the economy going with forecasts, what could be our losses on different portfolios based on the loan level detail, or what could be the growth in our balance sheet based on, again, loan level detail or deposit level detail that we have.

Advice for landing an entry-level data role

So yeah, I know the sentiment, I sometimes am able to interview candidates looking for those types of roles. And I will ask about their experience with Python and R and try and delve into their experience. If you can bring in any visual displays or if you have some projects hosted, it doesn't cost a lot to use AWS, say, for example, to have hosted projects for Shiny. I mean, there's free instances and other things and Shiny servers lightweight. I used to do that and have my own little public server. But that's even complicated because you have infrastructure. But now, Posit, you guys have solutions with Posit Cloud or there's another one. It's escaping me. But I used Shiny.io, if that's still around, I think. But I used to post projects there that were public knowledge that I could have available and that I could show if I needed to for demos. And so that's a great place if you're working on a project. Is Kaggle still a thing? Was that the name of it? Yeah, Kaggle. I used to get on there. But yeah, projects that you work on or if you can then demonstrate the visual analysis or tell your story through the analytics and do it in an illustrated way through either your markdown knowledge or your knowledge in Python, I think that helps.

Yeah. Thank you. Thank you for having me. It's my first time here at the Hangout. And my introduction won't be as long. I don't have that much experience. But yeah, I just started last June. I graduated from my master's in data engineering. And as soon as I step into the role, I started working with Posit Connect. It was my first time working with Posit Connect, and it has been great. The availability of sharing a link with my co-workers to get feedback and to get the analysis has been great. So my background is in data engineering. I was mainly interning before in projects related to cloud, AWS, and other more infrastructures and data, heavy roles, more in the ETL pipelines. And this was a little change on more of the analysis part. And I've been enjoying it, too.

One thing that I could tell when I was interviewing was, like Jason mentioned, having that experience. And one thing with AI now is you can really stood up some very nice projects to leverage. But that also means that everyone can have a project going on. So I would say more on doing a lot of projects. My approach was to focus on one or two and really go deep into those. I think one thing that helped was to do projects that are more specific. Like maybe if you do, for example, you hear a lot of tutorials on how to build a weather app dashboard or something like that. I would say take it a step deeper. You can go into trying to predict the floods against something. So always just try to go a little bit deeper because everyone will be leveraging AI, but we need to keep up with it. So that would be my recommendation for landing a junior role. One or two projects and really go deep in those.

Building the case for Posit Connect inside an organization

And, you know, when you do get to that point, which I had to do, you want to bring your, you know, you're going to have to engage engineering within your organizations to get this stuff through. And that's where, you know, I had to finesse my way through that. And so, you know, bring them solutions and you can connect with Posit on those, like what are the, you know, there's, we can manage the infrastructure. We have hosted solutions on AWS, just, hey, go to the marketplace, pop in this Posit Connect, go. You've got Posit teams on Snowflake now, which I'm trying to get our organization to test out and embrace. So it's not easy and it takes work, but you showing them options where they don't necessarily have to manage infrastructure can be beneficial to you.

Well, I'll tell you right now that alternative solutions to Posit Connect are very expensive. So for example, if you have a use case where you want to, well, you want to deploy a specialized app or something, the engineering resources that they might need to spin up internally to deploy that certain app would, you know, could run very expensive, right? And so I think the case, which I had to do this, you know, I had to build my business case. And what I did is I said, all right, look, here's the cost. At the time, the only available option to us was managed hosted infrastructure because we're a bank and I needed it to be behind AWS firewall and we had to control the images and all of that. So I had to build support for that for Posit Connect. And then I said, we're going to have this many developers and we bought Workbench and Connect, but they wouldn't stand up my Workbench because they didn't want to manage it. Okay. So I gave them the managed solution for now. At the time it was only on SageMaker. Great. So we did that.

And that's my IDE when we use it or people like Carlos and others develop locally and then push to Connect, but Connect was the main product I really needed to sell. So, you know, but I, we found really important use cases that were valuable to management, right? Where we could demonstrate value and then we align the stakeholders behind this deployment model, right? Where here you can have access to this information rapidly, quick, and we can manage the deployment and the code base and everything else behind it. And I'm not the only one who's going to be using it. I got this many more people that understand how to write code and can push this in there and potentially beyond just the administration. If, you know, students wanted to use it, that's another question. But yeah, so I think it's about demonstrating your use cases. If you have some simple things that you can deploy with Connect Cloud, then I would encourage you to connect with Posit to figure out which deployment model is going to be best for your organization, right? Based on the budget that you have available to you. And because there's all kinds of different licensing options. And if you're on AWS, you can do certain things at very low cost to experiment, right?

Dashboard design tips and tricks

Yeah, there are so many that that as you know, specifically to dashboards, the first thing I would do when I was asked to create a dashboard is I would step back for a minute and I would get out a piece of paper or a whiteboard, and I would try to draw it out visually. What do I want? And what does the stakeholder want? You got to get to the stakeholder. What are you trying to communicate to them? And often, the stakeholder doesn't always know what they want. So, it's your job to interpret what they're saying. And are you going to do a graph? Are you going to do a map? Are you going to do info boxes? And then how can you communicate? Then the second question is, okay, what's the data source going to be? And how am I going to access the data, right? And you need to design that in your head and keep that process separate from the dashboard. So, I always recommend write a... I mean, I'm speaking in the R world, but Python script or R Markdown, write a Markdown file that's going to generate and do all of your data processing first. Summarize it to create a CSV or Excel file or whatever, you know, or push it to an intermediate database. And then you have your dashboard file, which is your dashboard, which is going to read from that intermediate file, okay, and serve up the data.

So, to be more specific, doing that will allow you to separate the data generation process from the dashboard so that the dashboard can run independently when you update data, right? And we can get into all kinds of architecture discussions on that, but it's important because your needs are going to change, the data is going to change, and you're going to, if you do something really well the first time, someone's going to come to you and say, hey, can you update this? And if you don't make it easy to update, then that's going to be a challenge. So I always advocate separating the data process from that. Then the other pieces on the visual design, pick the right architecture, and then the page structure and keep your pages simple. Like I said, the Three-Click Rule, try to use the right tool for the right thing.

And if you're communicating for executives, you want to be able, they need to be able to go to the page and they need to see it and gather information from visual cues, whether it's graphics or info boxes. So for example, you could put an info box up there. When I read income in, if income were positive, I would make it green. If income were negative, I might make it red and put the change in there, right? So now the user can come in and quickly see, oh, my income's down, my loan growth is up, my this, you know, all of those different pieces. And they can gather that information with visual information very quickly in that case.

So yeah, Carlos, do you want to talk some more about dashboards that you've learned? You've recently deployed quite a few of them, so. Yeah, so like I mentioned, in terms of dashboards, I also started and I wish some of the things that I wish I would have known more in the beginning was the first one to emphasize is that modularity. Like it's a lot of, no matter how great you build it, whenever the first version goes out, you are going to get feedback on changing things. So make sure all the code is modular, you can move things around because there are some things that usually the user would say, oh, I would like to move this, and it's a big change. Or then another one, it's that they would think it's small, it's actually big. So modularizing is something that I really put a lot of emphasis in.

Then the other thing when I start doing these dashboards is I think a lot about the use case and who my target audience is. Just like Jason mentioned, if you're going to build something for an executive, you only have 30 seconds to read all the information that you have on. But if you're going to build something more for like an analyst, you can actually put more detailed information because an analyst might stay in the dashboard more and do more investigation. So that's how I like to preface my things. And then also one tip that Jason has told me and I mentioned a few times, that three-click rule. If people need to click a lot, then you won't be able to make them stay.

And then also some of the tips I've seen online is I like drill downs, but drill downs by clicking on different things. So if you have a KPI at the highest level of aggregation, let's just say you have a customer and then you click on it and you see all the different things that they have underneath and then you click again. And so that level, going down on that level of aggregation on one same page, it's something that I've seen stakeholders really like just that way they can see what they need to see. If they have a question about it, they can start a investigation a little bit more.

And then touching a little bit more on AI piece, I would say in this case, we use GitHub Copilot, but any AI tool that you would like to leverage, I would say start playing with it a little bit and start using one thing that changed completely my workflow was the different skills that you can put in the different AIs. That way the AI start building the code just as you would like it. Because some of the problems that I've had is sometimes I need a simple function or something and the AI writes something super complicated that I truly don't understand. So just trying to make those markdown files on how you like different things, I would say would be a good thing. And then the finish off, it would be, I would investigate different libraries that you have, just like Posit Connect. That is one of the good things about Posit Connect. It's not only Shiny, but you have R, you have Quarto, you have Trimlet. So I would say grab one of those and really go deep on that framework to get the most value out of it.

Balancing information in executive dashboards

I guess where I set out to change the world with dashboards in my former life, you know, I'd seen what people were doing in Power BI and Tableau at the time, mostly Tableau local. And I saw people without deployment opportunities and I saw these dashboards with like 25 zillion drill downs like, hey, welcome to my dashboard. You pick what you want to see. You can see all these, look at all these categories of loans that I can do. Look at all this that I can do. Look at all that. Well, that's forcing the user to make the decision and to go in and try to click at it. And they're gonna get it wrong. It's gonna be slow. It's not gonna be performant, okay?

And so, you know, this is where the conversations with the stakeholders like, what would you like to see? What are you getting at? What really is the key information that you are looking for? And this is where your job as a data scientist is to interpret that and figure out, well, okay, how can I display all of this information in a useful way? And how can I get it and make it intelligible? And so that's why like, instead of say, having a selector for each individual loan category on the same page, you know, I just created multiple pages. So it was easy to just click on the header at the top of the different categories and everybody saw the same page. They had the same information on each page, but it was, you know, different categories. So it made it performant, responsive, and they could see like the waterfall chart, for example. I love waterfalls in finance.

And the other thing I would do that I used to do is pre-populate certain fields, right? With default information, if you're using selectors or date variables. So if they're pre-populated to maybe the current year or the last 12 months, whatever you think the stakeholder's looking for, you know, that still allows someone to go in and select and change and maybe see two years, but having it pre-populated, it's just one less click they have to do. And so those are a few of my tricks and tips there.

No, yeah, great question. I've always actually said that building the dashboard is the easiest part. Knowing what the user actually wants to see and how to present it is the most complicated. So I guess it comes down, like Jason mentioned in the beginning, sometimes the stakeholder, because I don't know in your guys' expertise, but I've never had a stakeholder say exactly, I want to see this, this, this, and that. It's like, you need to kind of like get it out of him and to see, connect what the problem, because a stakeholder comes to you with a problem, but he doesn't know what data or where that data is. So your job as a data scientist is to kind of, like Jason said, filter that out and to see what KPIs he wants to see or what are those changes. So I would put a lot of emphasis in meeting with the stakeholder in the beginning. Don't write any code because if you write something, you're gonna have to redo it again. So I would say that those first stakeholder meetings on what you would like to see, present him with ideas way before even writing a single line of code will be the most important one.

I've always actually said that building the dashboard is the easiest part. Knowing what the user actually wants to see and how to present it is the most complicated.

Staying current as a manager and using AI to keep coding

A year ago, I moved up from data scientist to manager. I feel I am now no longer as close to the code as I used to be. What advice can you give me to stay up to date with data science developments? I go to presentations, but I feel I am being sold ideas that may not be realistic to implement.

I rarely have time for actually doing coding anymore. Every now and then I can get a burst of time to go have a little fun. How do I stay a little bit active on that? I mean, one way when I can have fun, since I don't have time to write the code, sometimes I turn to the LLM and I'll say, hey, can you go generate this? And in fact, I had a recent case where I was, this was with Posit Connect and some security issue on, yeah, you don't even wanna know, but it was on cross-site scripting. Anyway, so I actually asked the LLM to generate me a demo app to prevent cross-site scripting and this and that with secure modal dialogues and basically pop-up boxes that you see in your applications. But I asked, this is a JavaScript thing with Shiny and R, but the LLM gave me a great response and I got to go in, it wrote my code and I was able to go in and play with it and push it in, learned a whole new technique about how to use JavaScript with ShinyJS and calls to actually render a pop-up box in a quote-unquote secure way. And that was a demo I used for security to solve an issue and a question they had and then pass it on to other developers. So that's one way certainly to stay in touch.

I think that AI can help you do that to remain a little closer to the coding without feeling like you don't remember all these things that you know, like trying to build an app, where do I begin? And then if you're a manager and you have developers, I mean, continue to stay in touch with them, ask them to, put more work on them to stay up to date and engaged with the community and schedule meetings with them and ask them what they're seeing in developments in Python or R, right? What techniques are they bringing into their development with the, and continue to participate in Posit calls and public forums or Python calls and conferences. So, and then you hear something, push it down to your team and ask them to figure it out. I think that's where as a manager, I do that all the time. So I get on with Posit. In fact, with Carlos, we had this situation where we were trying to do some massively parallel computing and the team wanted to use Spark, which is a little old, but we got on with Posit and with the solution engineer and they said, hey, have you looked into Dask? And it was a smaller group and we hadn't heard of Dask. So then, but I turned it around and said, hey guys, can y'all look into Dask, go check it out in your parallel computation architecture and bring me back a report on which works, what doesn't and see if you can get it to work. So that's the role of the manager, right? You hear something, you see something, stay up to date and then push it down and see if your team can embrace it and learn it and bring it back to you.

Getting domain experience and acquiring dashboard feedback

Yeah, that is a complicated one because fraud is certainly an area where there's very proprietary data, right? I would recommend though that, one thing would be to reach out to people on LinkedIn that are doing roles where you think you might wanna be and see if you can engage them or work a network to try to find someone working there and figure out what techniques are they using because different companies use different techniques. Obviously, continue to go online and look for resources and trusted resources like Data Camp probably has some tutorials. Other areas will have fraud tutorials. I think there's even one, maybe an AWS on SageMaker AI, like one of their quick start examples, they might have something on fraud that you can try on an email basis. And I don't remember if that's probit or logit or LPMs or whatever they're doing, but or if it's just complete email with fine tuning. But like gradient boosting models and that sort of stuff. So I would look toward those particular demos and use cases and try to learn that. I mean, use the LLMs too to help you out, perplexity computer, I love perplexity. Tell it what you wanna do, how to get domain experience. The one thing I find exciting that LLMs can do pretty well is ask it to generate a synthetic dataset for you and then test your code on a synthetic dataset, right? So you could try to get like a real world example that way. There are tools too to help you create synthetic datasets for your objectives. So that way you're getting some domain experiences with synthetic data, so.

Yes, I love it. I have some advice. I know we have three minutes left, but if you already work in a big company, find out if you have a fraud department and then go express interest in cross-training, ask questions, find out what kind of fraud your company is trying to battle and then go meet as many fraud workers as you can and find out what they do, because there's like 50,000 different flavors of fraud. I worked in debit card fraud, which was very different from the type of fraud that somebody else might see. And once you understand how that fraud happens and how it needs to be handled, you can start to develop those synthetic datasets more easily yourself with fake transaction data and stuff like that.

Okay, well, we have two minutes left. I don't think that we can fit another question in, but I do want to say thank you so much, Jason. Thank you, Carlos, for joining us. This was so much fun. The dashboard zone was tons of fun, even though I'm a dashboard hater. I'm so glad that we got to have all these questions. I learned a lot. Jason, I hope that you had a good time. Thank you so much for joining us. Yeah, it's been a blast. I wish I could get to all of your questions.

This discussion, though, doesn't have to end here. I've been a firm supporter, a posit, in the community for many, many years, and that'll never change. And so you can find me on LinkedIn. I think it's part of my profile here that Libby might have. It's an easy way to connect with me. And our firm takes capital, and others, we are looking for different data backgrounds, and some they come across periodically. And certainly I can help direct to some of those areas on our jobs website at our firm. If you go there, I think there's some postings still for data analysts. But yeah, so in that regard, anything I can do to help or answer further questions, please do reach out, okay?

I just put your LinkedIn in the Slack. Oh, there it is, yes. Yeah, so everybody can go connect with Jason if they would like to. And I absolutely recommend somebody go out there and build a Shiny app that lets me pop in a chat file and have it come out restructured so that it's readable. Challenge to you all. All right, everybody, this was so much fun. I can't wait to hang out with you again next week at the Data Science Lab and the Data Science Hangout. Thank you so much for hanging with me. I'll see you then, bye, bye, everybody. Thank you, thank you for having me. Thank you.