Open source development practices | Isabel Zimmerman & Davis Vaughan | Data Science Hangout
ADD THE DATA SCIENCE HANGOUT TO YOUR CALENDAR HERE: https://pos.it/dsh - All are welcome! We'd love to see you! We were recently joined by Isabel Zimmerman and Davis Vaughan, Software Engineers at Posit, to chat about the life of an open source developer, strategies for navigating complex codebases, and how to leverage AI in data science workflows. Plus, NERDY BOOKS! In this Hangout, we explore the differences between maintaining established ecosystems like the Tidyverse as well as building new tools like the Positron IDE. Davis and Isabel (and sometimes Libby ) share practical advice for developers, such as the utility of AI for writing tests and "rubber ducking", and their various approaches to writing accessible documentation that bridges the expert-novice gap. Resources mentioned in the video and zoom chat: Positron IDE → https://posit.co/positron/ Air (R formatter) → https://posit-dev.github.io/air/ Python Packages Book (free) → https://py-pkgs.org/ R Packages Book (free) → https://r-pkgs.org/ DeepWiki (AI tool mentioned for docs) → https://deepwiki.com/tidyverse/vroom If you didn’t join live, one great discussion you missed from the zoom chat was about Brandon Sanderson's Cosmere books and the debate between starting with Mistborn vs. The Stormlight Archive. Are you a Cosmere fan?! Which book did you start with? (Libby started with Elantris years before picking up Mistborn Era 1 book 1, but she'd now recommend maybe starting with Warbreaker!) ► Subscribe to Our Channel Here: https://bit.ly/2TzgcOu Follow Us Here: Website: https://www.posit.co Hangout: https://pos.it/dsh The Lab: https://pos.it/dslab LinkedIn: https://www.linkedin.com/company/posit-software Bluesky: https://bsky.app/profile/posit.co Thanks for hanging out with us! Timestamps: 00:00 Introduction 04:41 "What does a day in the life of an open source dev look like?" 09:43 "What got you into building your own R packages?" 13:00 "Personal tips for working with code bases you're not familiar with?" 16:35 "How much of what you build is in R/Python vs. lower-level languages?" 19:57 "Does Air work inside code chunks in Positron?" 20:12 "Changing the Python Quarto formatter in Positron without an extension" 22:56 "What do your side projects look like?" 26:40 "How do you approach writing documentation?" 30:55 "What interesting trends in data science are you noticing?" 33:38 "How do you leverage AI in your work?" 37:30 "What are the hexes on Davis's back wall?" 38:50 "What career advice would you give to someone in a similar position?" 43:45 "How can I be more resilient when things go wrong?" 47:59 "Do you have keyboard preferences?" 49:25 "What is the best way to report bugs in packages?" 50:56 "Open source dev work vs. in-house dev work" 51:50 "Tips for getting started with Positron"
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Hey there, welcome to the Posit Data Science Hangout. I'm Libby Heron, and this is a recording of our weekly community call that happens every Thursday at 12pm US 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.
I would love to introduce our guests today. They are Isabel Zimmerman and Davis Vaughan. They are both software engineers here at Posit. I'm going to let them introduce themselves. Davis, would you go first and tell us a little bit about what you do and something you like to do for fun?
Sure. Yeah, my name is Davis Vaughan, software engineer at Posit. Things you might know that I work on are the tidyverse, like currently I'm working on the next large dplyr release. I am the co-creator of air, which is the R formatter that's used in Positron in RStudio. And then I also work on most of just the R infrastructure that actually powers Positron. So that's about me. At home, I'm in my athletic shirt. I really like CrossFit, so I'm generally in the gym five times a week. That's my de-stressor. It's my barbell therapy, as we like to say, after a long workday.
Nice. Aw, I used to do powerlifting, and it was the best thing ever, and I miss it every single day. All right, Isabel, how about you?
Hello, everyone. I am Isabel. I mostly work on the Positron IDE. That's probably 99% of my week. So if you have played around with the Python side of the Positron IDE, I've touched really a lot of things. I primarily work on the Python experience. I've also built some packages, like the vetiver, and I maintain pins as well. That is the Python flavors of these packages. If you're familiar with the R side of these packages, that is Julia Silgi, who maintains those. I am the Python half.
But outside of work, I am actually just on, like, coming back home today, within the last, like, 12 hours of a tour of being a nerd. So I was in Salt Lake City four days ago for Dragonsteel Nexus, which is Brandon Sanderson, who's an author. All of his books and everything, like other sci-fi fantasy books. And then I went from there to Boston, where I was at PyData. So I was talking about Python data science tools over there. And now I'm home. So if I act a little like I've been all over the place in the last seven days, it's because I have. And I am so excited to be here with everybody today.
I was so excited you're here, too. I know when we were talking last week or the week before, I was like, well, Isabel, you're going to be loopy when you get to the Hangout with us. It's been a long road. But yes, I see we have some Sanderson fans, some Cosmere fans in the chat. I am, too. I'm a huge Cosmere nerd. So getting the three of us together, because Davis says, too, is a little dangerous. We'll try to stay on topic for data science. But if you want to talk about Cosmere books, we are down, all of us.
Let me say something. And Isabel is modest. She was not just talking at PyData in Boston. She was keynoting at PyData in Boston, which is fantastic.
So modest. Thank you for shouting that out so we can make sure that we all clap. I have given one lightning talk in my life, and it was the most terrifying thing I ever did. So keynoting, I cannot imagine. Well, we have so many questions that are already just pouring into Slido. So let's hop over to Slido.
Day in the life of an open source developer
There was an anonymous question that came in first. So let's start there. And this is for both of you. It is what does the day in the life of an open source dev look like? For more established things like the tidyverse, is it more maintenance work as opposed to something newer like Positron where there may be newer features to build? I'm going to throw this to Davis first, since tidyverse was mentioned.
Yeah, so as you were talking, I was just pulling up exactly what you're saying. So yeah, I mean, you know, day in the life of them is not too different. Like, it's a lot of either rust, or it's R or it's C. It's just kind of whatever is demanded of the current thing. But like, in terms of what I'm working on, sure, dplyr has its like maintenance and whatnot. But there's also fun stuff. Like, we're currently working on like, these two tidyups is what we kind of call them. They're like proposals for new ideas. So we've been proposing this idea of like filter out as kind of a additional function that goes with filter. So this is like a new verb for dplyr along with some other vector functions. We can drop a link in a second if you're interested in these. And then there's another one that's like all about like recoding data in the tidyverse. So there might be some, there's some new recoding functions coming like that expand kind of a case when family to these other ideas about like recoding when you have a lookup table or something like that. So there's lots of new fun things that beyond just like maintenance work that happened in dplyr. But certainly everything on the Positron side is new, like it's all very fun stuff. Sometimes it's harder than the dplyr stuff because it's like this massive like IDE that you have to work on. But I don't know. It's very different. It's very fun. It's all very unique. Every day is different.
Yeah. Marcus put in the chat, like one obvious difference is dplyr has less than 80 open issues and Positron has like 1600 when something is new and also huge. Like an IDE is so different than a package full of functions. Yeah. That's, I think that's a big difference. Isabel, what about you? What's a big difference for you between maintaining something that is more established and building something that is brand new and also like software versus a package?
Yeah. I think the tooling is very different. And really the size of team is something that I personally felt like when I was doing vetiver and pins, Python packaging stuff, it was really like Julia was doing the R side. I was doing the Python side and we were collaborating in that way, but we were getting a lot of impact. And like mostly what we were deciding was what we wanted to do and a little bit more from the community. Positron, we also are super driven by whatever people are giving thumbs up to in GitHub issues. So if you want to see something get fixed in Positron or a new feature in Positron, giving a thumbs up to a GitHub issue is like probably the best way to add signal to something. But the tooling is different. I write TypeScript code, which I had never written for vetiver or pins before. But it is a lot of, you know, seeing what people are interested in. It's a lot of Positron is a little bit more set up. Like I had to download a bunch of different things on my computer to get it all running. And the development cycle is a little bit slower on a larger project like an IDE, just because there are way more moving parts, you know, making sure this change doesn't change all of these extensions or the experience in the console versus, you know, your Python script itself. So just a little bit more of like larger scope of what to look for when you're making changes.
That's true. Is it a little bit more reactive as well? Because with Positron, it's built on another framework and there are all kinds of things that might change that are outside of the scope of your control that you then have to react to to make sure that Positron still works with them?
There's a lot of upstream maintenance that we do. So Positron is a fork of VS Code and we also have other places where there is an upstream. So every month we are making changes, not only our changes, but reacting to whatever Microsoft has done on VS Code. And if you ever look through the Positron repository, changes are often tens of thousands of lines of code that we have to review every single month. So there is a maintenance burden, you know, working off of a fork as well and being reactive to that.
Navigating unfamiliar codebases
It is what are your personal tips for working with code bases you're not familiar with or getting up to speed on inherited, complicated code? And I have thoughts of my own. But we'll hop back to Davis for this one as well and I'll hop to Isabel after. Do you have any tips, Davis?
Yeah. So, you know, I was just, I'll share my general tips and then also one new thing. So, like, it's a lot of just, like, getting in there and looking at the examples and the tests, I feel like, are actually a really nice way to kind of understand how something works is, like, I go and look at the tests and I run them and that actually gives me, like, little slices of examples of what the thing is supposed to be doing. Because often, like, if there are no documentation and, like, a really, really big package or whatever, like, I just don't know what a certain thing does. But, like, looking at the tests is often a nice way to get an idea of how this thing is supposed to work.
But recently, like, with all the AI stuff lately, like, Leonel Henry, one of my colleagues, has been using this thing called DeepWiki a lot, which is, like, you give it a GitHub repo and it will, like, index the whole thing and then you can just ask it questions and it will, like, how does XYZ work in this, like, in this package or whatever? And it will give you pretty detailed answers about how it's supposed to work, even without documentation. Like, it will analyze the whole repo itself and then give you some kind of, like, documentation that's easy to consume. So, stuff like that, I think, is actually pretty good use of AI and some kind of, like, how does this thing work type question, which kind of gets you unstuck a lot of times.
I would have to echo a lot of what Davis said. I think tests are a great place to start. I also think perhaps this is obvious, but perhaps it's not to, like, use the thing first and think about, like, okay, I used this class when I was trying to build this model and then kind of following the path that you know is most used to help understand kind of framing of what people are doing. AI is also getting really good at looking at even very large code bases. So, I often will be, like, can you just explain this to me to, like, Cloud Code or whatever and it does a decent job.
Excellent. And my advice is I have a sticky note that says aggressively ignore in all caps because I'm a side quester and if I get into a new code base and I'm trying to help somebody debug something, I get so distracted because I'm, like, oh, I don't know how this whole thing works. Therefore, it's too overwhelming and I can't figure out anything. But if I aggressively ignore everything else, and I got this advice from another programmer who gave a talk and I can't remember his name. So, I'm, like, plagiarizing here. But if I aggressively ignore everything else and, like, okay, well, I need to fix this one thing and I just use that thing that I need to fix as the root of my exploration, how do I figure out how just this one thing works, its inputs and its outputs? I can get through so much more easily and then that gives me a little bit more context about the entire code base and then I can go from there and branch out.
Building packages and tools
I made my very first R package for the first time last year. And it's, like, the reason why I got into it was because I had a really, like, organic thing that I had just grown into. So a lot of functions that I was writing over time, and I was like, okay, this needs to be brought into a better place. If you guys have worked on building your own R packages, like, what got you into building it and what were the resources that you guys relied on?
I think R packages are just, like, the vehicle for doing really cool things in R. So it was just this desire to, like, build really neat things. Like, when I started at Posit, it was RStudio. And when I started then, it was wanting to work with Max Kuhn on, like, building out tidy models. So he had this big vision of, like, I want to build tidy models. And I was like, that sounds amazing. Like, I would love to join you. And R packages are just, like, the vehicle for sharing those kind of, like, things with the community. So I really enjoy, like, all the tooling that we've built around it. Like, dev tools and use this make it so easy to get started with an R package. But just being able to share, like, really cool things with the community is why I love it and why I still do it.
Yeah. I think mine was more of, like, a villain origin story where I was doing MLOps at a different company. And, you know, there were these tools that were made for, you know, moving models around. And it felt like it was more built for, like, a cloud architect persona rather than a data scientist persona. And Posit at that point was still called RStudio, but had a job opening for MLOps Python packaging. And I thought, you know, I've had these exact struggles. So maybe I can be part of the change I want to see in the world.
I've had these exact struggles. So maybe I can be part of the change I want to see in the world.
Writing documentation
Okay. I think I have a bad answer, which is it's a skill, and it helps if you just write a lot, and then especially, like, explaining it to a coworker or a friend or a dog of, like, how would I show someone this package? Like, if I had a reprex or, like, your reproducible example, what would I give to somebody to, like, do the most common path through this package? So, I think, like, the idea of a getting started page, which is I mean that is essentially what a getting started page is, is often, like, the most important page on all of your documentation for people who are just discovering a package. I use tools like Quartodoc. So, if you're familiar with the Python land of, like, Sphinx, this is kind of like Sphinx, but it uses Quarto websites, which I am Quarto's number one fangirl. So, I think having the right tooling that makes writing docs accessible and feel easier for you really helps as well. I was not a huge RST fan, so being able to find a tool that made writing docs a little bit easier felt good. But I think, yeah, giving somebody something they could just copy and paste to get started and just a little bit of prose around it. This is maybe another place where AI is helpful to be, like, hey, imagine you're a beginner who's never heard of this before. Does this documentation make sense? Or what am I missing? I think are good places to start if you don't have someone to pair through documentation with.
Yeah, I love it. It's like when you build a chart and you're, like, I understand this. Give this to your partner and be, like, hey, no background. Do you understand this? And if they have no clue what's going on, you have a pretty good idea that you need to make some changes. Davis, how about you?
It's certainly a skill. And, like, the places where I felt like I had to exercise the skill when I was starting, like, vignettes, like, this type of getting started, like, page. But, like, there's two things that I really like about writing vignettes. One is that I feel like I step back and I have to, like, write a story, kind of. Like, the best vignettes to me are when they have, like, one data set and you go through, like, 10 different things in the package that you can do with that one data set. So, the user isn't, like, context switching between, like, what the data actually is behind the scenes. And they can focus only on, like, what are you trying to teach them about this package and how it works. And then the other thing that I really like about vignettes is that it kind of proves to me where I have holes. Like, there's, like, holes in dplyr if, like, as you're writing the vignette, you're sitting there going, why is this so hard? Like, I can't figure out exactly how to write this or it's really hard to explain. If it feels hard to explain, we've probably just done it wrong. And that gives you a good chance to go back and be, like, let me try this again.
Trends in data science
It is what are interesting trends in data science that you're noticing? And there was a little follow up on it because you can add replies in Slido that says I've noticed that people are coding more using multiple languages and a workflow rather than just solely coding in R or Python. And I noticed that I do that myself as well. I'm, like, oh, I know this better tool in Python or this better tool in R. And because I'm in Positron and it's so easy to do both, I will combine them. Do either of you have thoughts about trends in data science that you're noticing?
I have a micro trend that is Python specific where people are pulling out Pandas as a dependency. So, a lot of times in Python, like, plotting libraries, modeling libraries, you would have your default data frame to be Pandas. And so, you would carry this around as a dependency. But with the rise of new tools like pollers, which is way faster and, like, rust backed, not everybody is using Pandas all the time. So, there's actually this really cool tool called narwhals that you can it's, like, data frame agnostic. So, a lot of people are, you know, well, I guess, removing Pandas and putting narwhals in its place. But just a little bit of, like, shifting to allowing people to have more options, which is probably really similar to this multiple languages trend where, you know, people are learning that there's so many cool tools out there and being given the option to use them for the right task. That is a very, very niche Python trend that I've been seeing a lot.
Awesome. Davis, any trends or micro trends that you're seeing?
Yeah. I think, to me, it's, like, opinionated tools are, like, where it's at. Like, rough and air are very opinionated, but, like, very well loved. And then, like, UV is, like, another thing that's, like, it's got some opinionated things behind it. But, like, they have just crushed it in, like, terms of virtual environment management and package management in Python. And, like, it very much feels like we need something similar in R that's, like, also very opinionated, but then just, like, crushes it in terms of, like, you know, it's outside of R. It's a command line tool that's opinionated. And I don't know. That feels like where it's at in terms of, like, tooling lately.
Leveraging AI in your work
Speaking of trends in data science, we had another anonymous question that was how you leverage AI in your work. So, do you leverage it? Testing? Helping you figure things out? Learning? What are your thoughts on AI?
How do I put this shortly? I used to be, like, a big AI skeptic. I didn't use it very much. I didn't want to. And I still don't use it a ton. But I do find, like, I get a decent amount of value of Cloud Code when I ask it in very certain ways to do things. Like, I always have it make a plan first, and then we can, like, reevaluate the plan together before it actually does any work. Like, I find that I get a ton of value doing it that way. I use it to write tests. I use it to rubber duck quite a bit. I use it for things that are just, like, more monotonous tasks. I don't really let it go haywire in terms of, like, writing an entire new, like, dplyr function for me or anything that typically requires too much, like, overall architectural knowledge and thought than what I can explain to Cloud. But I do use it. It's just not, like, for everything all the time. It's not, like, it doesn't feel like it's, like, replacing me. It just feels like it's enhancing me.
Yeah, I think my intro to AI was using it for tests because that felt like a well-scoped, safe place to start with AI. As I used it more, I feel like my most successful use cases are places where I know exactly what the code was going to look like, but maybe it's, like, quite broad. Broad and, like, multiple files, many lines of code, but I know exactly how I'd want to structure it. And, like, AI can type faster than I can. So being able to review the code that I knew what it was already going to look like is way easier. There is this, like, weird changing of, you know, like, burden of, you know, are you more of a reviewer now than somebody who codes if you use AI all the time? And I think, like, maybe in some ways I've gotten better at reviewing code now that I do it slightly more often as I review AI code. But I also try not to let it just go haywire. And it is a dangerous game if you're sending your colleagues code that you haven't looked at. Like, that doesn't seem like a good way to practice or a good standard of practice for anybody. But, yeah, I think there's definitely places where I really enjoy it and I think it's useful. But I would not let it go off on its own. I would not vibe code in prod. Maybe for a side project. But that's kind of where I stand.
Career advice
If you were going to give somebody a piece of career advice who was in a similar position as you in data science or in engineering for data science, what would it be? And I will put Isabel on the spot first.
Yeah, I know you had prepped us that this question is coming and I feel like I've had a lot of, like, cheesy one-liners that go through my head about it. So I'm going to cheat and have two small pieces of advice. One of them is just quoting you, is stop networking, start making friends. I think it is, like, the most beautiful thing. Like, at PyData, I just sat and, like, nerded out with somebody about crafts for so long. And, like, she's the leader. It's Faye. She's the leader of PyLadies Boston. Coolest human being ever. And I think having those, like, genuine fun community connections are amazing. And also doing it scared. You know, like, if you're scared of, like, I don't know how to write a package. That's fine. Like, do it scared. No one's going to judge you. And if they do, like, that's on them. That's not on you. So try it anyway. Don't worry about being bad at things. That's the beauty of being a beginner. So just do it scared.
Yeah. So mine is stolen. Stolen from Hadley, actually. He has said before that he purposefully made a decision a number of years ago to just be nice to people. Like, in his he gets GitHub comments and issues all the time that are, like, people being super frustrated with something, super upset, like, mad at him kind of thing. And, like, he has the ability to, you know, say whatever he wants back. But he always takes a moment and is just nice. Like, he's just nice to these people in return. Because, like, you never know exactly when that is going to, like, who's going to see that message. Like, what kind of community is going to be built around that. Like, he's in a position of a lot of, like, influence these days. And just by being nice, he's been able to, like, have that trickle down throughout the entire, like, our Entity First community. Like, we all feel like this community is very nice. And I think a lot of that is in part of people being at the top, like, are also just very nice people.
He purposefully made a decision a number of years ago to just be nice to people. And just by being nice, he's been able to, like, have that trickle down throughout the entire, like, our Entity First community.
Resilience and keeping going
Data science and infrastructure really interest me. But it's so easy to get discouraged or feel like I'm beating my head against a brick wall when something goes wrong. How can I be more resilient and keep coming back to it?
It is hard. I mean, it's hard when especially when, like, it's a project that you're not necessarily that interested in and you're having issues with it. So, like, if it's a project that you're, like, would love to see this thing completed, like, I feel like it's a lot easier to, like, learn the thing that you're struggling with. Like, you're willing to spend the time because you, like, have a feeling that the outcome is going to be worth it. So, like, my only advice there is try to find things that, like, really interest you if you're also learning something new at the same time. And, like, kind of coincide those together if possible. It is very hard if, like, you're just not that interested in the thing and you're struggling with it. Like, that's, I'm sorry, that really sucks if that's the case. Like, that's very hard to learn something new.
I like to think of my code as, like, it's a living document, you know? It's a living tool. It's going to change over time. And, you know, like, I've gotten some bad haircuts, you know? So, like, if you write code and you have to take it back out later, like, oops, your code got a bad haircut. The hair will grow back. We'll fix it. So, I think realizing that things will change. You're going to write bugs. You're going to write amazing things as well. And, you know, the only way, it's cheesy. It's cheesy. It's bad. But, like, the only way to truly fail at it is if you stop and then you never come back. So, keep going.
As a person who teaches adults to code, I will tell you that learning things and sucking at them as an adult is hard. Like, we've lost our sucking at things muscle because when we're kids, we suck at everything we're learning and nobody cares. So think about learning a new language that's a spoken language. Little kids don't care that they say things wrong. Little kids don't care that they only speak in incomplete sentences. Little kids aren't shamed for, you know, talking in sentences that are sort of caveman-like, right? As we're learning a new language, a spoken language as an adult, we beat ourselves up if we have to talk like that because we think that we need to have a discussion about profound topics. No, you just have to learn to speak in those basic sentences. Be so much nicer to yourself and also don't do it alone. Go make friends. Go join the Discord, hang out on Blue Sky. Don't do it by yourself.
Reporting bugs and getting started with Positron
What is the best way to report bugs in packages? I'd imagine that it's best to include a small example of the issue, but I'm not sure where I would go to bring attention to it.
So we'll drop some links, but there's a package for helping you create reproducible examples called reprex. So that will help you create the thing that you need to share, but then where to share it. Like if you have an issue with dplyr, for example, like you can go to dplyr's issue page on GitHub and you'll just see like a whole bunch of issues. So you can open a new issue, drop in your reproducible example right there. And we love to hear things like that. We want to know when things are wrong. We want to know when it doesn't do something that you would hope it would do. That's how we learn like what the gaps are inside of dplyr or inside of the tidyverse and it's how we build it out to be kind of what you guys need.
Fantastic. I think that covers it. Isabel, do you have any add-ons? No, I think that covers it. As long as you have something that we can like copy paste and reproduce the example and clear steps, that's going to make it 1000% easier to solve your problem.
Do you have any quick tips as we go? Go ahead, Davis. There's lots of fun extensions out there. Like I think adding the fun theming and stuff that makes it just look really cool is just like a fun way to get started. And it kind of shows you how like unique and customizable this thing is and particularly in compared to RStudio. Like it's really quite fun once you get started with Positron. It's just a fun place to be and work in.
I would say learn how to open up the command palette. If you know how to, it's command shift P or there's like the little search bar at the top and you can like click that and it gives you a bunch of options. That is your guiding light throughout all of Positron. And that would be my one tip for everyone who's getting used to it.
That's it. That's the bridge of the enterprise y'all. Everything happened there. And you can type in a word that is like mostly like what you're looking for and it's going to help you figure it out. So if you want to have fun, open up Positron, command shift P, and then type in theme and go up and down and change your themes. That's the most fun thing to do for me in any IDE. Also go into your settings in the search bar and settings, type in RStudio and turn on the RStudio key bindings. Your life will be better if you're coming from RStudio and you would like to do both in Positron.
Okay. This was a fantastic time. I hope that you answered my awesome poll in Slido. And oh my gosh, thank you all so much for hanging out. You're going to love our last hangout of the year is coming up and it's Josh Starmer of StatQuest. If you are like me, you stan Josh Starmer. You love and watch Josh Starmer. So please come meet him. Ask him all the questions. Isabel and Davis, thank you so much for hanging out with us. You want to say goodbye to everybody Isabel? Bye. Thanks for having me. This was a delight.
Yeah. Thanks for having us. It's been a great time. Nice to talk to you all. Thanks for hanging out. I'll get Davis and Isabel's episode of the Data Science Lab up soon on YouTube. So look forward to that and we'll see you next week on Thursday or at Tuesday at the Data Science Lab because Marcos is joining us. Bye everybody.
