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.