Hey everybody, and welcome to another episode of React Roundup. I am your host today TJ Van Tol and with me today on our panel I have Jack Herrington, Hello, and Paige neding House. Hey everyone, and our special guest today is Chris Bruin. Chris, how's it going? Welcome to React Round Up? Hi, Thanks for having me. Yeah. So Chris, why don't you start by telling us a little bit about who you are, what you do, why you're famous, all that good sort of stuff.
Okay, yeah, famous might be questionable. Yeah. So I'm currently a full fac software engineer at a startup called in Club and it's based around Zurich, Switzerland, and we're I guess we're trying to be if you could imagine kind of Airbnb but for experiences. So I'm going hiking this weekend. Who wants to come with me? Or I mean going on a pub crawl? Who wants to come with me? And so, yeah, I've been there now just over a year. Yeah, from everything from back end, mobile
app CMS, everything in between. So I've seen a little bit of everything. Awesome. So I know we reached out because you've written a couple of really interesting articles about your thoughts, like I think all sorts of things from
like code structure to testing, how BDD like behavior behavior driven development. So maybe do you want to start by just giving like an overview of some of like maybe we could start with like BDD and like how you came to like how you structure code and how you approach problems at the startup, because I not a whole lot of us get the chance to really, like green Field build something like that at scales. I'm curious, like some of your thoughts
and opinions you have to share around that sort of thing. Sure. Yeah, So the challenge for us was that we we were a very small team, so up until a few weeks ago, I was kind of the only developer, So it was me and the two co founders. So as you said, yeah, super Greenfield, and we actually we were guided. One of our technical advisors told us about this kind of behavior driven development thing.
So we're like, okay, what is this and so he he pointed us, I guess at the very top of this whole like behavior driven development and test driven development stuff is this language called Girkin. And so Gurkin is simply you could consider it like a programming language but it's also kind of yeah behavior and kind of product design language. So basically the only the three important keywords are given when and then, and for us developers, that kind of corresponds
one to one to the whole the act arrange, assert Trio. So the reason he the reason he pointed us in this direction is that the two co founders, they're kind of the minds behind the product and driving a lot of the ideas behind the product. They can describe in playing in English or with these three sentences right, given let's say, given I open the app, when I press the log in button, then I see the login screen, right something like that. They can explain steps in very plain English. And
then we or I I guess it's we. Now there's there's two of us. Now that's awesome. We can write the tests against these kind of Yeah, these we call them Girkin special specifications. It's pretty cool. And it's spelled just for anybody else curious g H E R K I N just for anybody just casually googling this as we go across, because I would not have guessed that's spelling at all. Yeah, I believe integrate with jest or how do I if I'm if I just want to start with this or where do
I start with this? Yeah, so there's there's two kind of two ways. The one way is you can use a library called the Cucumber, with which they have actually drivers for a lot of languages, I think also Plain, Java, JavaScript, Cotlan, other languages, So you can use that and they you basically directly import like a function called given and then you pass the string of whatever the given line of that description file is. But yeah,
we've we have since integrated with jest. There's also there's an integration you basically so when you write these these specification files. We we're using the dot feature file extension that seems to be like kind of a standard, and this just integration works that you you import, they have like it's called like a load feature function and then just knows oh okay, I'm reading from this feature file and then you have defined feature with more more in I guess a standard
just way. But still with these you get these little given when then functions that you can you can call from just in the order of the steps. Oh nice, Yeah, I found that it's just dash cucumber on GitHub and you're right, it like it looks to me like any other just all these nouns. It's kind of sometimes you take a step back and go, like, these sentences I'm saying are a little crazy, but it looks like any other just test that I've seen before. But you're right, it clearly has
the given when then type of structure just sort of embedded within it. And that's really interesting that you've been able to incorporate that into a testing framework because at the last company that I worked with, our product managers were responsible for writing a lot of our feature stories, and they would use that sort of syntax to write out the story, so exactly like you would say, given a user clicks on a button, when they are given a users on our
application, when they click on the input button, then I should open up the input or the login screen. But we would then translate that into our own tests, where it would be like tests or it should xyz. So that's really cool that you can just take it directly from the user's story or the user input and make that part of the test, because it's like, if you don't meet that criteria exactly, you know there's something wrong with the code, not the or how it was defined. Maybe but that's really cool
that you could have that one to one comparison. Yeah, I mean I think there's there's huge advantages. I mean, what what you just described is is amazing, right, Like the basically the product development team or the product management team can kind of have a one to one bridge right to the engineers.
And what what we also found now that we have we have this new developer on, you basically have your whole infrastructure more or less, you can say hey, like or if you know, if they they're asking about what does this feature do or how does it work, you say, hey, don't read the test. Read the test second, but first read these read these feature files. It's and then you can understand, Okay, I see
exactly these user stories in plain English. So that's that's super valuable. So you keep around the like plain english, verys of these requirements then, so it's not just the tests that that live on Yeah, yeah, these are these are checked right intoto the code base. So with that said, like what what page was mentioning, Sometimes we can write the test directly as they're written. But but sometimes, I mean it's it's been a constant learning process
for both of us. I mean for example, we had features where it was like, you know, you have a form, and it's like if the email is wrong, I see an email error. If the first names wrong, I see a first name air. But I've learned, like, okay, that should probably just be like in a unit test for like the form validation function, right, that doesn't probably need to be always like you probably don't need to write every test in this in this given one men syntax.
It's it's it's kind of like a pick and choose and it's a constant like yeah, it's it's a discussion between between us and the product team. So it would this be more of a replacement for like EEDE tests then, I mean I wouldn't necessarily writing unit tests this way. I guess you could like more, Yeah, you're you're right. That's that's where we've found it's the easiest, right because end to end tests are much higher level anyway, which we're much better with. Like I press the spot and I go to
the homepage, I find that my name says Yeah. I've never used this structure for actually implementing tests before, but I have used this when working with like product people before, and the other kind of nice thing I think about this format is is it forces product people to give more specific requirements for things
as well, because I'm sure a lot of you can resonate with. Sometimes you'll get these requirements that are like vague or they have or they're complicated like yeah, or are they don't yeah exactly, they don't consider things beyond and like this sort of forces you to say, like, Okay, well, when this happens or this scenario, when this happens, what should happen?
Right, what happens with these account types? What happens if they try to log in and they already have an account or it's an in veiled email or the servers down or whatever. Right, So it gives you like a clear just means of specifying requirements. Yeah, and then and then even better like when when you do get that feedback, then you still have this these descriptions and these scenarios for those the unhappy path or when the service down, given
the surface down, what happens? So yeah, I think I used this at a previous job, and I remember there being like part of was on us to actually go and build out like the regular expressions like enable the terminology like when I do X I see law and like you kind of like we're writing regular expressions to match some of the English terminology of the test. Yeah, is that you find yourself doing that a lot already? Is that not
not so much? What do you mean exactly? Or well, like there were expression matchers for the terminology in the test because the terms knowledge is written in kind of an plain English speaking style, right when I go to the page, I ended up actually having to write like pattern matchers for some of that stuff. Yeah, it depends, I guess, I'm not sure what you mean exactly. So do you mean like the because the given or you mean the body of the test itself? Like what? Yeah? Yeah,
yeah, yeah, so yeah, that's we we typically have done. What we've been using a lot, especially in these end to end tests, is just like a test ID if you're if you're aware with those of those.
So yeah, this the the whole thing behind test IDs is a bit it's considered sometimes anti pattern, I guess, but what we realized is because it's also because the whole kind of startup environment features could change like two weeks from now with different even you know, different UI elements, different texts and and everything like that. So some of the other matchers like get get by store. Yeah, get by elements don't make so much sense, at least from
from our opinion. So when you have this test id, Yeah, it's difficult. I mean sometimes the test id itself kind of gives way to what it is, like a button or at least like a touchable. We're working
and reacting to a touchable opacity. So one question I have you said, you do you store a lot of these requirements in actually in the code base, So how do you handle like the location of those especially for things because occasionally you'll have requirements that aren't specific to say, like a page, right, Like they'll have to be like I do something on one page and then
I go back to another and something should happen sort of things. I do you have like app level requirements or like how like how sort of pedantic do you get about that? And how do you sort of handle that sort of thing? Yeah, that's that's something we're still working on. So far. We've we've had like a set usually you have like five or six of these feature files per feature. But then we've also like the engineering team as also
we've kind of designed our own feature files. Still still to this, which I could hear, I could hear a lot of people out there would be like, well, that's a waste of time. But it's still going back to this idea that you have. You have a catalog of of everything that that you you're testing in the catalog of these features. So typically, for example, like these end to end tests, we've written ourselves in the Girkin syntax with which has these kind of cross you know, multi page stories and
things like that. Yeah, it's it's difficult to it's difficult to balance that like some should I explain, because you can't ask like the product team, they can't write a feature file probably for a specific function in your code base, right, they don't know about it. So it's really uh, it just comes down to reading, reading the features and saying, okay, where's this going to go? More than more often than not, it's probably going
to go into an integration test or end to end test. But even then you may even want to break down or talk with them say yeah, okay, let's let's take these scenarios and put them in a different test or that actually belongs with a different feature or grouped with other features. It's quite it's quite challenging. Actually, I'm not sure that that's probably a horrible or or no good answer there, but you know, because I think everybody struggled.
Yeah, well everybody struggles with this, right, Like I think this is the just a common thread of software development no matter what system you use, like where you put tests and where how you organize require ements and how you maintain them over time is a constant struggle. So if anybody had the magic bullet answer, we'd all be just doing that. Yeah, one thing I can say to that at least is that we so we have like for our end to end tests, which are supposed to be like the least you know,
the top of the pyramid, least used and whatnot. What we do you have there is like only the we call them like business critical stories, right, so like can a user check out? Can they do this? Other? Like typically like so we have at in club, we have you can create your own experience of course, like you can put in the title description these things we have as end to end tests, because yeah, they're
they're the most important. But in terms of yeah, in terms of unit tests and integration tests, well, currently we're a bit more lax with those, of course you should, you should have all your test passing before you go to to production. But just in terms of way they're designed, a lot of a lot more of them are just written by us, the software team, and there's not maybe not a feature file yet for those. So
so that actually leads into my next question. And you touched on this a little bit with the testing pyramid, but how much how many integration and unit tests would you say you have compared to your end to end tests. What's your percentage? Yeah, we we have. We're kind of weird. The middle middle of our pyramid is very fat, so the integration level, and I think that comes a lot from like React itself. You can argue maybe a small component is like a unit test, but probably in reality you're you're
gonna need something, some component from somewhere else to test your components. And and that's the biggest part of our our code base. I mean, we have the unit tests we do have are only for we have only I don't know a dozen or so, and those are for our big, like, our most critical functions. Ideally, I mean, everybody wants the ideal world where you have one hundred percent test coverage. Every function, every component. Well, okay, maybe we don't as a software developers, maybe we don't
because we'll go crazy. But yeah, it's so we have. I would say, how to maybe like fifteen fifteen percent unit and end to end, so on the on the two ends, and then the rest is all is all integration. Yeah, that's just what we have currently. No, I think that makes sense. I'm also, like we've had conversations before. We're we're not on team hundred percent unit testing coverage here at this on this show,
we're very much pragmatic. And I think it's even beyond pragmatic because if you have a goal of one hundred percent test coverage, that puts in sort of like weird incentives as well, like you end up just writing tests just to do it versus whether it's actually providing value to you as well. Yeah. Yeah, and then they get these meaningless tests and if they break, you're not quite sure why what are you testing? What was the intent here? And all that? Yeah, I mean well, no, no,
I'm happy to riff on this. I was going to ask a the IDCD question, but we'll get there. No, I was just going to add one final thought that I mean Your unit tests are code too. You have to maintain it. Your requirements are going to change, they're going to break, So your test should be doing something versus just being there. So you hit the hit the lines of code to make your your whatever code coverage tool
happen. I think you should always have some rules, like if we do a certain type of change, we don't want a unit test to break. Like if we if we make a text change to a button, you don't
want a unit test or any contest to pass. That sounds like chaos tests jack, well, you know, but like if you if you like make a spelling fix, like that's you know, come on, yeah, you know a little I'm talking about like the little blurbe texts, like you know the things that snapshot test car here, yes exactly, Yeah, basically just trying to ward people off of snapshot testing, like please don't do that. Well, okay, so Chris c i CD, So when do you just
to kind of dig into the whole DevOps thing here? So when do you run these tests? And how do you like a headless thing? Do you run in c CD? All that very soon we will run them in c i CD. Okay, but that that has a lot more to do with with me being the solo guy, and I didn't the whole trouble with with Apple. Building has to be on a Mac and the only although native Yeah, yeah, and the tooling is the tooling is tough, and although Apple
is releasing a cloud. But yeah, I run the test locally before before release or when we're getting quite close. But that's very soon to be added now that I have some help from from our new new developer. But doubled the engineering team size for us. But yeah, I think the typical the path is simply I like to throw in the the type check that type check's empty. That's actually my first test, even before unit and then the unit
tests, then integration and then end to end. When you say type check, you mean like typescript checking, yes, the ts Yeah, actually we can. It might be overkill. That might have been a bit of overkill from me, but we wrote we converted ours into a unit check, like we get the output from TSC and if it's zero lines, the unit test
passes. So although I I did that, and then I realized later I was like, yeah, I could just run the bash command as part of the pipeline, Like yeah, I think it could turn that like into a husky step too. Yeah. Yeah, so Chris, another article you have that I think it's kind of interesting you make the case for one function per file, which could be potentially controversial. I don't know how the other hosts feel, but why don't you start by making the case for this? Why
one function per file? Yeah? So yeah, I've worked with a lot of code basis. Typically I think it's a React pattern. It might be almost like a legacy React pattern, is that you'd have, you know, you'd have a bunch of exports in one giant file called like I think in my blog post, I use like a math as an example, right, so you could imagine ad subtract divide. Okay, great, but then if you if you use them first, you import them and then you've got this
big import from one file. But the hardest or the most confusing thing for me from that pattern is that when you're in this function file, you're looking
all over the place and jumping around and I don't know. I like, if I open a file, it's just I can see hopefully if the function is well organized, should all fit right on the screen, right, And then I have it and The idea there and how it relates to testing, is that when you do a unit test, you import this file and that's basically other than all your test tooling, that should be the only file from
your codebase that you're importing. And then you're sure that at least in a unit sense, this is like what's under test, like this single thing in my code base. Yeah, I'm trying to decide if I like it or not. In my head, I'm going to go with dislike. I mean, I can imagine at least maybe as a compromise, like one exposed function, like because I definitely do things where I hide like internal stuff as if somehow add in the math context we're a complex thing to do or something.
Well, but you could argue you could make a function within a function a JavaScript, you can throw functions anywhere. Okay, sure, don't do that in a React component. I've seen that before, people making like subcomponents inside inside of the declaration of a function component. That is bad, Like, do not don't do that. Sure, I'll actually mess up React if you do that. But in math, if your math, if your function needed to do some like repetitive thing over and over again, you could do that.
In my My argument was, if you had this sort of math function, you can organize them by the file name and the subfolder, so like math slash ad math slash subtract. Yep, Okay, I maybe I'm like I suspect I'm in a small minority. Yeah, it just feels like a lot of files to keep track up instead of just one that has all of
your related functions together. Yeah. I feel like now I'm just bringing up like a bringing up like a code base and looking around because I don't know, like dread my good base at the same time, Like I can see though, like I do, even if I don't totally agree with one function per file, like definitely, like it's definitely an anti pattern to be building like these monstrosity files that I think most of us have worked on, right,
Like even if like we maybe can't get on board fully with swimming things down to one function like once your file, like I've had I've worked at places where we had rules that like once you reached a file reached a certain number of lines, it would spit out some sort of warning, right like you're you're over like three hundred lines in this file, Like are you are you sure you want to keep Are you sure you want to keep going the RB dragons. I just refactored a graph you OL server file that I had.
There's twenty four hundred lines. Oh my god. I remember you might want to consider this one function per file, right, But now I understand like why he says his unit his integration tests are so large because if an integration test is defined by a test, because integration tests are a weird definition anyway, but if it's defined by a test that includes more than one file, then yeah, no, man, if you have one function for file,
like ninety percent of your tests are going to span across multiple files. Somehow, It's true, very controversial. I would say, yeah, yeah, it may have been just my reaction to seeing I've also worked with some of these giant files and I just said, nope, nope, just keep it simple. One per file. That's my rule. Yeah, we'll see. Maybe we also have to refactor some of our functions. I look at me that if you hit command P and so you're now searching around on files
in VS code, different IDs have never ones. But if you're doing command P, then an you type an AD, right, you'd get if you have one one function of or file. You get it, that's that's kind of cool, as long as okay, don't do the thing you have like an ad directory like slash mask slash ads slash index Oh no, no, index imglentation and then index that'sc or test dot Oh god no, then you
a billion indexes. So, Chris, when you joined the company that you're working for, now, was it completely greenfield where you just got to build this app from scratch and make all the design decisions, the architecture decisions, what libraries were using, what stack or was there something that you inherited that you kind of had to take and build off of. It was it was definitely inherited, and it actually was a lot of what Jack just mentioned infinite
index JS files. Uh, that's yeah, that's also that's part of why I went to that this one file one function for file pattern. But in the other the other struggle, at least from a from a JavaScript or now typescript perspective, is that they had it was a weird mix of there was I was seeing typescript syntax with with JS file extensions and everything in between. And actually, that's that's something nice we've we've achieved very recently is there's no
more typescript theres in the entire code base. It took a long time, but we've finally gotten there. And now it's great because you can, for example, like we just upgraded a package. Then you just run TSC and you say, okay, they changed. You know, of course you read the documentation, but you find immediately where in the codebase that that the changes
are. And so these types don't work here. Before when when we had five hundred typescript theres anyway, they were just lost in a sea of like confused and you don't know, you don't know where there's like errors hiding. See I was. It was a big takeover. And of course there were also no tests written. And I still think tests in general are kind of
I might be biased from my own experience. It was one of the last things that I kind of learned and I'm still learning as a software engineer, but I think it's a lot of because we all like to when we test, we'd like to run just run the app or click around and use it ourselves. Right, That's like it's kind of the natural, your natural way to go. But but I really see now the value of having automated tests and it gives you security and we're not not security, but a better feeling
about what you're shipping to. Just another layer layer of uh yeah, of keep in mind. Yeah, yeah, definitely. Yeah, you can always get down to zero warnings and zero well zero error is for sure, but zero warnings because otherwise, yeah, it's just it's white noise and people have taken ord after a while, you know, you know, and then yeah, yeah, oh no, nobody touched that function because if we touch it
or change it, you know, nobody knows what happens. Yeah. So, Chris, do you have any other tips there from being like a solo developer starting on like a big project like this, do you have like any any other thoughts or people things people might find interesting from going just going through that experience. I think I think the best thing you can do is just to I want to say, write one function pro file, but no really it's uh, the best thing you can do is try and be organized or
right right code. That's you know, thinking about this, like this file length limit. That's almost true, especially when you work alone, you can't really afford to have these big complex functions and components and even on a bigger team, you probably shouldn't. So I think my number one advice would be to try and write code that's like small and manage in small, manageable parts
that work together. Yeah. I think I can definitely see that because if I'm left to myself, if I'm coding by myself, I definitely have a different mode right where I'm far more willing to just go this. This is the wild West, right. I have my giant function. I know what it does, does what it needs to do right, and I don't think
about it too much. Whereas if I'm working on a team, I'll approach it like, well, okay, page is going to see this and have to figure out what it's going to do and how that's going to work, So I might think about it a little bit more. So I think I would struggle in that role just because I don't know my my apps would fall
apart at scale because I would just be lazy about it. Yeah, I mean I had to fight the same thing too, right, But but the hope I kept in mind, I was like, yeah, soon soon there will be someone on the team, you know, you know, with the vision that that we're growing. I mean, we are. We are growing slowly too, but the division that more people, more engineers will be writing
on this codebase. So yeah, yeah. Every time i'm ass to value about a codebased and it's a single coder on it and it's been there for a year or so over a year, I'm like, oh, that's going to be, that's gonna be somewhere's weird stuff going on there. Yeah, single engineer or also like contractor written. That's That's been the other red flag for me too. Oh yeah, just because when someone's not accountable to the team, right, they just just somebody just has to see something working to
sign off on it. Then things can often get hairy. I would be a strong fan of the single function profile if I was a contractor in getting paid per file. There you go, I'll do it, yeah, exactly at one constant profile. Awesome, Well, Chris, have we We've covered a lot of ground? Is there anything we've missed, Like any articles you've covered, any topics that that we haven't got into that you you wanted to
discuss it all. I think one thing I was going to mention before we got into the whole ci CD and the function pro file discussion, a huge thing that we've learned or it's quite simple really is like, because you know we're talking about all these tests. You have all your tests, they pass great, but most often, of course, bugs are either like super weird or user reported that nobody expect or saw. And one of the best kind of patterns that we've done is like, Okay, we get a critical bug
or either a very weird bug or something. Then you write a test specifically against that bug. It maybe it wasn't in your feature files, wasn't in your specifications, but write a test against that bug or fix the bug, of course, and then write a test against it to kind of make sure that it doesn't come back right that it doesn't. There's no limits. Agree on that one. Sure, So yeah, that's one thing I forgot to
mention. But that's I mean, even that might even be if you want to if your work somewhere and maybe your organization has no test yet, that may be one of the first places to go or the easiest way to start writing tests. Yeah, it's also very satisfying if you can get it, like get it to show up as red and then you implement a fix and then feel confident to like get to see it switch over. It's very it's a very satisfying feeling too exactly. Yeah, cool, what's been awesome chatting
with you. I think we can move on to our picks. So it's where we just pick something movies, TV show music. We're still waiting for somebody to have a strong musical take. The do a lot of TV shows. But Jack, do you want to kick us off today? Yeah? Sure, we're not. My daughter and I just finished up the UCS Millennium Falcon build, which is I like, it's a Lego build. It's just enormously huge, you know, it's like, I think seven thousand parts and
epic. Yeah. How long did that take? We're kind of old hands at the Lego thing, so it took us three and a half four days. Wow, But it was you know, it was we basically traded off on it and it was fun. You know. So if you're into that sort of thing, it's a it's a fun build. I will say that if you are into movie speak. It has a lot of us called greebles, which are just basically little things that you put on something to make it
visually interesting. So there's just a lot of stuff on there, just like it doesn't. I'm actually not functional. It's just kind of stuck on and it's just a lot of that, like you build a structural piece and then it's like a bunch of like just add a lot of little bits of Yeah, it's fun, awesome, cool page. What picks do you have? My pick for this week is going to continue on the kitchen tools train. So this is a plastic wrap dispenser. So normally when you get plastic wrap,
it comes in those those cardboard boxes. The little cutters not very good if there is a cutter at all, or just rips and terrors and stuff. So we bought a bamboo wooden food dispenser. It comes with a really nice little top cutter and it works like a charm. It's really heavy so you can just pull the wrap. It doesn't slide across the table after you.
The cutter works really well. So I would definitely recommend that if you have twenty dollars to spend, get one of these things and you'll probably never need another one. I've probably seen one of these bike behind a sushi bar or something when they're like making the rolls. Yeah kind of thing. Yeah, awesome. My pick this week is going to be a weird one,
kind of a very specific one. But I'm going to pick Amazon Go, which I don't know if any of you have went to one of these stores before, but you'd have to be in either Seattle, Chicago, or New York. So that's why it's a very specific pick. But there are these stores by Amazon where their core tech is there's no checkout, you just grab you at the door. You go in, there's these turnstiles and you scan your phone in the Amazon app, so it knows who you are, You
grab whatever you're going to buy, and then you just leave. And the system there is smart enough. There's cameras. The entire ceiling is covered with these cameras and you just get a notification on your phone a few minutes after you walk out with just a receipt of what you bought. And I'm picking
you just because if you're in the area. It's just fascinating to do because because it's it's just such a weird experience, right, like you feel very very strange, like you feel like you're actually committing a crime when you walk out of the place. And for me too, we went with the whole family. So you go in as a group, and I was just amazed at the technology because we said, we had two eleven year old kids, right, so of course they're just grabbing things off the shelves, putting it
on and off, you know, walking around whatever. And sure enough, we bought like five or six things between the four of us, and it perfectly knew exactly what we bought, charged us perfectly, and I was just kind of amazed by it. So if you're ever in the area, for if you're a listener in one of those those three areas, it's it's worth doing ones just to experience it. Is there any security there? Can you just like just walk out? You literally walk out there? There was not
another There was not a human employee in the store. There might be somebody like in the back or something for all I know, but we did not see in a single employee. It's kind of crazy awesome. So, Chris, what picks do you have? I guess I'll do the two books. The first, I guess this is quite relevant. It's uh, we've we've all read it on the team. It's The Lean Startup by Eric I think Rice you pronounced it his last name. It's quite interesting and yeah, there's
a lot of good stuff packed in there. So yeah, that that's my first and then I guess, well, the second is a series of books, the Foundation Series by Isaiah I guess it's it's made a kind of a resurgence recently because I think Apple did a series on it or something. But yeah, Apple, the books are awesome. I recommend to read the books first because it seems like an unfilmable show and it kind of was. Actually is. It's a science fiction Oh yeah, okay, I'll have to check
this out. Cool. Well, Chris, last question for you. If people want to follow you, what so, what's the best place to to do that sort of thing? I guess the easiest is just my blog. It's uh, it's Chris Frew dot I N And I think from there you can find find me anywhere. I am trying to get back to making YouTube videos, but I've been extremely busy with the startup. But I hope this Yeah so cool. Well, thanks so much for joining us. It's a lot of fun to chat. Yeah, thanks a lot. It's really fun.
Cool And then until next week, everybody, alright, see them Bye.