Jamon and Jon Major enlist Mark Rickert to help in Robin’s absence. They talk about open source, dependencies, and … skydiving?
Jamon and Jon Major enlist Mark Rickert to help in Robin’s absence. They talk about open source, dependencies, and … skydiving?
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth
Welcome back to React Native Radio Podcast, brought to you by the IRS who's already aware of your dependencies. Episode 204, own your dependencies with Mark Rickert.
Jamon Holmgren:
Hey, Jon Major, Robin is out today, do you think that we can do this ourselves?
Jon Major Condon:
I was planning on just leaving too. I think we could just cancel it maybe?
Jamon Holmgren:
Cancel, yeah. She carries us every week and we're going to be exposed.
Jon Major Condon:
Definitely. I am going to have to talk more.
Jamon Holmgren:
I think that might be a good thing, have a little more of that because clearly Robin's the one dominating the conversation when we're all together. Hi Robin, I'm usually the one doing that. Yes. No, we're going to give it a try. We're going to see what we can do here. Luckily, we have some help, we have some reinforcements. So I'm Jamon Holmgren of course, the, I guess regular host of React Native Radio. And with me is Jon Major Condon, who is my remarkable cohost.
Jon Major Condon:
Hello.
Jamon Holmgren:
And I appreciate you joining me today and keep me a company, but we do have help. With us is Mark Rickert, he is going to be a guest host today. I'm really excited about this. Mark is a principal software engineer at Infinite Red. He lives in Asheville, North Carolina, at least for the moment, and is an extreme sports enthusiast. Is that even what you call it, Mark? Do people call themselves extreme sports enthusiasts in that community or what is it called?
Mark Rickert:
Yeah. I guess it just depends on whether you're a professional or not. I don't make money by jumping off of buildings and bridges or jumping out of planes. I just do it for fun. So I call myself an enthusiast, but there are people out there that get paid for it on the Red Bull teams and stuff like that, but not me. I'm just an enthusiast.
Jamon Holmgren:
Well, okay. Yes, but this is a little aside, but you have released software in free fall before.
Mark Rickert:
Yes, I have. I have a skydiving app in the app store that shows where all of the closest drop zones are to you. And I actually released the first version of that in free fall at about 12,000 feet. I taped my cell phone to my arm with a bunch of duct tape so I wouldn't go flying down to the earth and waited until I got out of the plane and had cell phone signal. I was low enough to the ground to get cell phone signal and I hit the button in the app store, connect app.
Jamon Holmgren:
Okay, so there's actually a video of this and we're going to link to it in the show notes-
Jon Major Condon:
Oh, I have not seen it.
Jamon Holmgren:
Yeah. You're going to have to see this Jon Major, but were you, so here's the thing that I'd be worried about. I'd be worried that I get to like, hey, this isn't working, what's going on here? And start debugging it on my wrist and then just smacking to the ground. Were you worried about that?
Mark Rickert:
Not really. A lot of people like to call people like me, adrenaline junkies, but I don't really see it like that. The adrenaline fades away after a little bit of time. And then you start focusing on what can I do to improve my skills. And once you've attuned your body and your mind to that level of adrenaline and risk, other tasks seem pretty mundane. I've had a friend who got a tattoo in free fall one time.
Jamon Holmgren:
Wait what?
Mark Rickert:
Yeah, it wasn't a great one, but she got tattooed, a battery powered tattoo machine.
Jamon Holmgren:
Yeah. As free-fall tattoos go, it may not have been the top quality. Wow. Yeah. So as you can tell he's into things like obviously skydiving, base jumping, parasailing, wingsuit base jumping, and also just safe things like skydiving and paragliding and all the "safe things" he does. Also, you were a digital nomad for how many years?
Mark Rickert:
I think I lived in my van for six or seven years just traveling around the country. Yeah.
Jamon Holmgren:
And you're a little more settled down now, but you still have that digital nomad roots and well, that's almost an oxymoron there, but that's where you enjoy being, untethered and moving around, which is pretty cool.
Mark Rickert:
Definitely. When I found out that I could just live in a van and work on my computer for a while, I jumped at that opportunity. I sold everything I owned and I was living as a digital nomad and working for Infinite Red. This isn't an Infinite Red commercial, but we are hiring senior level software developers.
Jamon Holmgren:
I did not even prompt you to do that. Well done Mark gets a raise.
Mark Rickert:
Yes.
Jamon Holmgren:
How long have we known each other Mark? It's been a long time now?
Mark Rickert:
We have, we started working together I think back in 2013-
Jamon Holmgren:
You had a Mohawk back then.
Mark Rickert:
I did have a Mohawk. Yeah. I don't know what else to say about that.
Jon Major Condon:
Was it colorful?
Jamon Holmgren:
You know what? When I search my memory, I seem to remember it was pink, but I don't think it was actually pink.
Mark Rickert:
It was not pink, I have very dark hair and it's very difficult to dye, I've tried.
Jamon Holmgren:
Oh, okay. But I was working on some open source and you just showed up in there. I'm trying to remember how that went.
Mark Rickert:
Well, yeah, I was basically starting working in this new niche programming language. I'm not sure if we should say what it is since it's not React Native, we don't work in it anymore.
Jamon Holmgren:
I don't have any problem talking about it. It was Ruby based, it was called Ruby Motion and we built iOS apps with it back in those days.
Mark Rickert:
Yeah, for sure. And I was working on some iOS apps for my personal company and Jamon Software library did 95% of what I wanted my app to do as far as the navigation structure. And so I was like, okay, this is going to get me 95% of the way, what can I do about this other 5%? And so I just started sending poll requests. I made it do what I wanted to do. And it seemed like people appreciated that. But the first time I actually contributed to one of Jamon's repositories, it was just a read me update. It wasn't anything substantial. It was just a way to help others figure out how to contribute because I went through those pain staking steps.
Jamon Holmgren:
Yeah, totally. And that's always a great way to get started. If you're in the audience and you haven't done open source, if you just contribute to a read me update, that's always appreciated by authors. For one thing, it's really easy to review it. You just look at it and yeah, that makes sense. And you merge it. There's not really a certain thing.
Mark Rickert:
Yeah. I think my second poll request came 45 minutes later and it was stripping out a bunch of white space. So it's like, there are things you can do to contribute, to help make a project better even if it isn't writing some crazy code that does a million things. And so that was really my first introduction to Jamon, He surreptitiously merged all my pull requests and we started a friendship from there. We started working on projects together. Eventually started working together at Infinite Red and we wound up together in a hotel room in San Francisco.
Jon Major Condon:
Well, do tell more.
Jamon Holmgren:
Yeah. This is how all of Mark's stories end, is we ended up in a hotel room together in San Francisco, this is a true story by the way.
Mark Rickert:
No, we were roommates. We were both small business owners and trying to cut costs because we were both speaking at the same conference. And so we banded together even back then to help each other, so.
Jamon Holmgren:
Yeah. That was fun. I remember it so fondly, it was awesome hanging out. You were pretty busy though, you had a lot of things going on, but we did get a chance to hang out at that conference. And that's also where I met Todd and Ken and Gantt and my future business partners, which was fantastic, as well as some of the other people at Infinite Red to this day. But we should get down to business. We've got a really cool topic in front of us and a lot of notes and we want to get through that. So let's move into that. I'm really happy to have you here, Mark. Appreciate you jumping on with us.
Mark Rickert:
Yeah. Thanks.
Jamon Holmgren:
Should mention, this episode is sponsored by Infinite Red. We are a premier react native design development agency located fully remote in the USA and Canada. You know us, if you've listened to this, if you don't, go check us out, infinite.red/reactnative. Don't forget to mention that you heard about us through the React Native Radio Podcast because Mark might get a little bonus if you do. I don't know. I came with that.
Mark Rickert:
In the notes section of where you heard of us, just say Mark.
Jamon Holmgren:
And as Mark mentioned, we are hiring senior React Native engineers out of the US or Canada. So go to careers.infinate.red for that. All right. Let's get into our topic for today. The title of the episode is, own your dependencies. We actually got this from Artsy, which is a company that actually previous guest Orta, worked for back in the day. And he actually mentioned it in the episode that we talked about TypeScript with Orta. He works on the TypeScript team now, but he said that one of their core mantras was, own your dependencies. And I love that. It's so cool. It's such a great way to think about things. Because I think I know, Mark and I have done a lot of open source and there are people out there who are entitled, they'll come into your open source and demand things and want things a certain way. And it's like, hey, it's open source. Be like Mark and just go in and improve it.
Jamon Holmgren:
And so own your dependencies. And no, we're not talking about the child tax credit in the US-
Mark Rickert:
No, not own your dependents, own your dependencies.
Jamon Holmgren:
Jon Major has a few kids, I've got four, Jon, you got like three?
Jon Major Condon:
Three.
Jamon Holmgren:
You got three. Okay.
Jon Major Condon:
And Mark, if you want some dependencies, I can ship them over to you.
Mark Rickert:
No.
Jamon Holmgren:
Yeah. We've got a few extras.
Mark Rickert:
I'm perfectly fine with me and my partner and my cat.
Jamon Holmgren:
So we are talking about co-dependencies in generally, NPM modules, but there's also, CocoaPods, there's Gradle dependencies. There's also stuff that you can copy and paste into your own code base that could be considered a dependency in some ways. There's STKs, there's various libraries and whatnot that you link in from excode and Android studio from the native libraries that come with the platforms. But generally, in the case of what we're talking about here, we're going to mostly focus on NPM modules. I think a lot of it will be generally applicable to other dependencies as well. So, first off, I want to actually ask you Mark and Jon Major in the project you're currently working on, how many direct dependencies do you have listed in your package.json, including dev dependencies?
Mark Rickert:
I went through and I looked at the current project I'm working on, which is a very large enterprise application. And it's a React Native iOS, Android and web project. It has 124 dependencies defined in the package.json file.
Jamon Holmgren:
124?
Mark Rickert:
124.
Jamon Holmgren:
That's 124 different libraries that you're bringing in directly and that someone else has written generally speaking?
Mark Rickert:
Correct. Yeah. And those are things that I've added in there, or it came with our template that we started with, but then there's a nice yarn command that you can run called yarn list. And then if you give it a depth, it'll actually go and tell you exactly how many dependencies are at each depth. And so when I look at the first step, I have 1,754 dependencies. And so that means that each dependency has on average, about 10 sub dependencies. If we go another level deeper, I've got 2,600. And then at the final level, I've got 8,181 dependencies and sub dependencies and sub-sub dependencies from those 124 explicit entries.
Jamon Holmgren:
And some people will be like, ah, those are rookie numbers, in ours, we have whatever. But that's pretty normal. Jon Major, did you check on your project?
Jon Major Condon:
Yeah. It's about 110 ish.
Jamon Holmgren:
Yeah. And I feel like that's fairly normal for a mature React Native app, to have around a hundred ish dependencies, direct dependencies. And as Mark said, it gets bigger and bigger. Now, there are a lot of duplicates in that. If you look through the yarn list, you'll see that there are a lot of duplicates, but often they're different versions. So even if it's a duplicate, it's a different version. So dependencies are by far the vast majority of the code that is running in your project. The vast majority, the code that you write is a minority. And yet we don't really talk about this. I don't think we talk about it enough. So I'm really, yeah. This is going to be a good topic. So Mark, when you're adding one of your 124 new dependencies to your project, how are you deciding that, hey, we need a new dependency and this is actually something we need.
Mark Rickert:
The biggest thing is to ask yourself, that question is, do I need this? Do I need this code that someone else has written? Do I need to integrate this into my project? Does it provide significant value to me versus something else like copy and pasting one snippet of code that you need into your project. You have to really look at the overall ecosystem of a dependency to determine whether or not it's appropriate to add to your project. Now, the biggest thing I look for is widespread community support. That's a big deal for me, things that are out there that have thousands of stars that are not well-known in the React Native community, I have no problem adding those to my project if it does what I need it to do.
Mark Rickert:
Take for existence, like React Native maps, is there even another mapping library out there? It seems like that's what everyone uses. And so if everyone's using it, it's more likely to have solutions to issues you run across. It's more likely to have support in the GitHub issues or answers on stack overflow that can go and reference for people who've had the same problem. So adoption rate is definitely one of the bigger factors in my mind for adopting a dependency into my project.
Jamon Holmgren:
That's a great point.
Jon Major Condon:
So it seems also that size would be considered in this too, such as size of the code base. Perhaps just thinking about if this code base is so big, it's probably doing all these different things that you are looking for it to do, versus if a code base is pretty small, that could be something that you could copy and paste into your project itself.
Mark Rickert:
Yeah. Exactly. I had an instance like this, where I wanted to determine the distance between two latitude and longitude positions in my project. And the haversine function is a, it's a solved problem, we already know how to do it. And I found this dependency react, haversine or react, I don't remember what it was called. And I looked at it and it was just one function. And so I tweaked it, I made it a little better and I just put it into my project as a function instead of bringing in another dependency. Because you never know what's going to happen with those dependencies, there are people maintaining them and updating them and who, I don't know if the person that made this, if I trust them or not, or if I trust that their GitHub account is secure and that a hacker is not going to social engineer them into putting malicious code into my project from this one tiny dependency that I didn't need.
Jon Major Condon:
Did you then take that and publish it yourself?
Mark Rickert:
I did not because it's a known problem. There are so many places where you can go and find a haversine function in whatever language you want. I specifically wanted a TypeScript version of it. A lot of the examples out there are just regular old JavaScript. And so I found a good one and I modified it to use for my project.
Jamon Holmgren:
You mentioned security. And I think this is a big one. I've often looked at Laue like ecosystem of open source and being an open source contributor of some fairly good size libraries.
Mark Rickert:
Aren't you a core contributor on React Native?
Jamon Holmgren:
I am on React Native and MobX State Tree, primary maintainer there, Ignite, I've a lot of these library, too many really, React Native WebView means I do all of them poorly. But I do a lot of open source and I see the behind the scenes conversations that happen, in some of the teams, some of the core teams, there's a lot of conversation that's very thoughtful. It's very much like, we got to make sure that we're doing this right. And then others it's like, now the test pass, merge it and ship it. And that gives you a little bit of pause. It's like, okay, what exactly is in the library? And there have been situations where people have done what seemed to be semi innocuous, pull requests to popular libraries that are often dependencies of dependencies of dependencies, they're way down in the chain, so you're not even going to be reviewing them. They're not on your radar. They're way down there.
Jamon Holmgren:
If you have 8,000 dependencies of dependencies of dependencies, you just can't keep track of all of that stuff. But there have been situations where people have injected malicious code that deep into it. And it doesn't even, the PR doesn't even look bad, it just looks innocuous or they get control of the NPM space and they can publish there. And I know there's one situation where they published to NPM, but they didn't update the GitHub repo. So if you looked at the GitHub repo, the code looked fine, but the NPM source was different. And it was very like, who goes in checks that they match.
Mark Rickert:
Nobody does, but I'm here to say you should.
Jamon Holmgren:
Exactly. Well, there's a lot of you should here and I don't know if there's a lot of people going to actually do this, but.
Mark Rickert:
Yeah, no, but there are tools out there that can help you with these security audits. One thing that I actually recently found out about is a command called yarn audit. And if you're using yarn, I'm sure there's an NPM command that does something very similar, but the NPM website actually does security audits. And maintainers can tell you if there's a security vulnerability, and all you have to do is run yarn audit, and it'll come up with a list of all of the things that are wrong with all of your dependencies and sub dependencies and sub sub dependencies. I ran it on my project and found a cross site scripting vulnerability in a sub sub dependency, which I promptly updated. So yeah, there are tools out there that we can use to determine if we're vulnerable or not.
Jamon Holmgren:
Yeah. And those are obviously great for, and it is an NPM audit, and those are obviously great for reported issues, but you're still always rolling the dice a little bit, because there could be a very small, rarely used package that you have somewhere in your tree that just nobody's looking at. And the only person who would notice it is you, if you were to go look for it.
Jon Major Condon:
Have any one of you been on a project where there is internal review of a package code before it's included into the project itself?
Jamon Holmgren:
We've had clients who have had that process in place. Generally speaking, we're not as involved in that. We hand it off to the security team and they approve it and then we move on. But yeah, there are some companies that do that.
Mark Rickert:
Yeah. I was working on a project where they did a security audit of all the dependencies we were using for version one and then promptly forgot to do it for everything after that. So they're basically, we're saying we want to know what you're using but when we ask for this new feature use anything you need.
Jamon Holmgren:
Well, yeah, there's that age old conflict between security and convenience happening like that.
Mark Rickert:
Yeah. Exactly.
Jamon Holmgren:
Convenience pretty much wins.
Mark Rickert:
Always.
Jamon Holmgren:
So we know that there are risks to bringing in third-party libraries, but what happens also when it doesn't do exactly what you what you want. Mark, you said that my library promotion, back in the day, it did 95% of what you needed. You sent in some poll requests and I happened to release those, but that doesn't always happen. You could send in a pull request and it just sits there for a long time. What do you do then?
Mark Rickert:
Yeah, I would say in situations like that, when you're using a repository that isn't maintained by the owner, you're going into some dangerous territory because that opens up the door for new people to come in, possibly and maybe publish malicious code. Now, what I'm talking about here is probably the exception rather than the rule. And so if it's something that solves most of your problem and is not being maintained, you can always use tools like patch-package, or even just fork the repository and use your own fork. I actually prefer patch-package with extensive note in the Def as to why I've changed it. And when it should be removed generally with a link to a GitHub issue or something like that. So developers that come after me know exactly why I had changed this dependency to do something specific that maybe the repo owner maybe doesn't want to do or just doesn't respond.
Jon Major Condon:
And some places where you work at might not want you contributing to a project while you're working. I've been there. I have also contributed while I was working, but what I did also, from what you're talking about, Mark, at the time I took it and had a fork and was able to include it via the fork. I didn't know about patch-package until recently it's probably like, I don't know, a few months ago. Do you just want to talk about what patch-package is?
Mark Rickert:
Yeah. Patch-package is a really great tool. You essentially add it to your dependencies, that is a dependency of your project or you can use NPX to run the most recent version. And essentially, it allows you to change your dependency files after you've downloaded it from NPM. And so essentially, you'd run yarn to install your dependencies. And if you notice something isn't quite working right with one, you can actually go into your node modules folder, edit that file and then reload your application. And if you fix the change, all you have to do is run NPX patch-package, and then the Rebo name. And it will give you a dif that it then applies to that package every single time yarn downloads the package in a post-install script, essentially. And it just patches it on your local project instead of relying on some, a fork or a different branch or muddying up the actual version number of the project you want to use in your package.json. So it allows you to pin a dependency to a specific version and have your own changes built into it only in your local project.
Jamon Holmgren:
Yeah. And what's really cool about this library is that it'll also warn you when you upgrade that package and then you can go in and review your dif to see if it still makes sense or if they've fixed that problem. So it does a good job of staying on top of updates as well.
Mark Rickert:
For sure, it does. I had a situation where I upgraded one of the dependencies that I had patched and it told me, oh, we tried to apply this dif to this new version. It still worked, but you should double check and make sure that everything is done. We've already renamed it to work with your new version. So it's a very powerful tool that I actually use all the time.
Jamon Holmgren:
Yeah, it's fantastic. What about updating dependencies? So dependencies fall out of date pretty fast, and there's a variety of tools. So one that I really love is yarn outdated. You just run yarn outdated, and you get a list of all of the dependencies that are now out of date. And it'll also differentiate between, patch versions, minor versions and major version. So you can decide, oh, let's just update all the minors or all the patches.
Mark Rickert:
Yeah. Color codes them for you too.
Jamon Holmgren:
It does. Yeah. And it's very a very cool tool and you can do this all yourself. There's another cool tool called updater UPDTR. And you can run that NPX updater and it will run, or it will upgrade, basically it'll upgrade each of your dependencies that are outdated in order and run your tests. And if they pass, it'll go to the next one. If it they fail, it'll roll that back and then go to the next one.
Mark Rickert:
So you're saying I should write some tests?
Jamon Holmgren:
Yes. You should write some tests Mark. But what's really cool about that is let's say you're going to lunch. You just put that going, you come back, you get a report saying, "Hey, all of these ones, all these updates, your tests passed and all of these updates, they failed." So you know which ones you can just update fairly easily. And then the ones that failed, then you can look into why they failed and dig into it later. But updater is a very cool package. But yeah, yarn outdated is cool. There's also things like dependent bot on GitHub, but I found that kind of annoying to be honest.
Mark Rickert:
Yeah. Generates a lot of emails to you.
Jamon Holmgren:
It does. Jon Major have you used dependent bot or any of those other tools?
Jon Major Condon:
Haven't used it personally, I've just seen it lurking.
Jamon Holmgren:
You'll always see it lurking. Yeah.
Jon Major Condon:
Yeah. It's everywhere.
Jamon Holmgren:
I actually have turned it off and most of the repos I'm on because once in a while running updater or yarn outdated does the job for me. And I don't really care that some patch version of some dev dependency, like, oh, hey types, just updated on Node something or other, I'm like, this is like a build tool.
Mark Rickert:
Yeah. It's really important to when you're upgrading dependencies to actually go and look at the change log and see what's actually changed. Maybe you don't even need to update it because it was just a fix for something you don't need, or just a small read me update. And they decided to release a new version. There's all kinds of reasons that software maintainers release new versions. And sometimes you don't need to, until there's something that you need and it's less risky to leave the dependency alone than to upgrade it for a very minor reason.
Jamon Holmgren:
Yes. Now, I've got a question for you as we wrap up this segment, when should you not use a dependency and instead, just write it yourself? Mark, I noticed that at the end of our notes, you have this graphic that I think you paste it in there with, it's like a flow chart of when you should add a dependency.
Mark Rickert:
I actually just generated that in our Google doc together, making a flow chart of how I understand and make a decision.
Jamon Holmgren:
Oh, wait, that's an actual drawing in our Google doc.
Mark Rickert:
Yeah. I made a drawing in the Google doc and made a little flow chart for us to talk about how we should decide if we're going to put a dependency in our project or not.
Jamon Holmgren:
I like it. We're going to put a link to this, maybe we could host it somewhere and put a link to it, but it's it starts with, does this dependency solve your exact problem? If not, it is the code that solves your problem, a small part of the library? If it's no, then just write it yourself. This is a trivial library, it doesn't solve it exactly anyway, write it yourself. If yes, that it is a small part, then integrate the parts you need directly into your project. So just pull the small pieces into your project rather than having to pull in a giant library just to solve one problem.
Mark Rickert:
Yeah. That could add kilobytes or megabytes to your compiled program at the end of it.
Jamon Holmgren:
Exactly. If yes, this does solve your exact problem, then is there widespread community support? If so, go for it. Otherwise, if not, then maybe look for a different one or write it yourself. I like this. It's a good rule of thumb then and we'll try to link to that in the show notes. All right, cool. Well, we're running low on time, so let's move into the next section of this one. We're actually going to do our weird bugs section because I think Mark, you've got a weird bug. You've got a weird bug this time around.
Mark Rickert:
I do. I'm happy to say that a lot of my weird bugs have already made it onto React Native Radio.
Jamon Holmgren:
It's true. I swear half the weird bugs we talk about, come from Mark. Mark's really good about sharing. Like, hey, this is weird, check this out, in our Slack and I love it because it's always fun, like shop talk. But you know what, go for it. You've got a weird bug that you've been tracking.
Mark Rickert:
So I've been tracking this weird bug for quite a while now. It was originally reported on the React Native GitHub in October of 2018. Essentially, the bug is when you have hot reloading turned on, on the iOS simulator. And I'm not sure if this works in Android simulator because I do most of my development in iOS simulator and then just check it in Android. So most of the time I'm in the iOS simulator, if hot reloading is turned on every once in a while, if you've been working on it for an hour or more, you might get two dev menus popping up when you go to reload the application hit command controls, the whatever, you get two dev menus that appear. People have said that it only happens on device, but I get it in the simulator as well. The only way to really deal with this is to close Metro, close the simulator and rebuild the app.
Mark Rickert:
And so I've seen this come up multiple times, that happens to me maybe once or twice a week. And I just have to reset everything. There's been multiple questions as to what's actually triggering this and nobody seems to have an actual answer as to why this is happening. So we'll post the issue link in the show notes. And maybe you could go and read through and figure out if you can fix this weird bug.
Jamon Holmgren:
That'd be awesome. Yeah, that'd be quite annoying. And apparently, it's just been very difficult to get to the bottom of it. Okay, cool. Well, I think that's a wrap. So where can people find your Jon Major online?
Jon Major Condon:
Sure. I'm basically everywhere @jonmajorc.
Jamon Holmgren:
And that's J-O-N Major C.
Jon Major Condon:
Yeah. J-O-N Major C.
Jamon Holmgren:
You can find me @jamonholmgren and Mark, what's your Twitter?
Mark Rickert:
Well, I don't really do social media very much. I'm actively trying to remove it from my life because I think a lot of it's toxic, but I do have an Instagram account where I post videos and photos of my crazy adrenaline fueled sports. If you want to go check that out, it's @markrickert.
Jamon Holmgren:
You also have a YouTube channel, which we can link to as well. And people need to go check out your, although I scanned through your YouTube channel. I didn't see the releasing an app video. I don't know, was it on a different channel or?
Mark Rickert:
No, it's on the same channel. I'll have to make sure that it's there in public. I don't know.
Jamon Holmgren:
Okay, cool. Yeah. Well, we'll make sure we get that linked in the show notes. You can also follow React Native Radio @ReactNativeRdio. Thanks to our guest host, Mark Rickert. Thanks so much for being on Mark. It's been awesome.
Mark Rickert:
Yeah. Thanks for having me. It's fun.
Jamon Holmgren:
As always thanks to our producer and editor, Todd Werth, our transcript and release coordinator, Jed Bartausky, our social media coordinator, Missy Warren, and our designer, Justin Huskey. Thanks to our sponsor Infinite Red, check us out infinite.red/reactnative. Special thanks to all of you listening today. Make sure you subscribe. Send us to a friend. And also we are hiring React Native engineers, if you're a senior level React Native engineer located in the US or Canada, go to careers.infinite.red. See you all next time.
Mark Rickert:
See you next time.