Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
H m hm.
Speaker 2 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.
Speaker 3 (00:21):
Hello and welcome back to another episode of the Angular
Plus Show.
Speaker 1 (00:25):
My name is Laara Newsome. I am here today with
Chow Chow. How's it going?
Speaker 4 (00:30):
Uh good and tired, but I'm here. I'm here to
learn more about playwright because I use playwright at work.
Speaker 3 (00:37):
Yes, nice, nice, yeah, And Chow's been uh For those
of you not living in the Midwest of the United States,
it is. It has been a like steam sauna the
last few I think steam sauna is the proper setting
for what we're on. Yeah.
Speaker 4 (00:54):
We got we got extreme heat wanting the past week
or so.
Speaker 1 (00:58):
Yeah, yeah, so it's it's nice out. Yan Yan is
with us as well today. How's it going pretty good?
Speaker 5 (01:08):
We finally have a seback A s broke down last
week in you move to the glorious country of ac
and then it's like it breaks down. You'll just like great,
So now I have nothing that this country is worth
looking for.
Speaker 3 (01:23):
I will say, like on the opposite side of that,
like the new house I moved into.
Speaker 1 (01:27):
My bedroom is the coldest room in the house and.
Speaker 3 (01:29):
It is the most delightful thing that's ever happened to
me as an adult. So just like laying there, I
could feel the air conditioning hitting my face and it's
it's the best thing.
Speaker 1 (01:38):
In the world.
Speaker 3 (01:38):
But anyway, yeah, or not really here to talk about
air conditioning, but I will say it is the one
thing I don't know if I can live without. Anyways,
on that, we'll stop there put in that. Our guest
today is de Wi O'Brien, Debbie. Welcome back to the podcast.
How are you today?
Speaker 6 (01:55):
Hi? Everyone, Well, I am feeling hot because we are
in the middle of this heat wave that you seem
to have. God do you send it all over to us?
So we're on thirty nine degrees today and luckily I
do have air conditioning in this room, so that's why
I'm staying here and working is better than being outside
for real.
Speaker 3 (02:13):
Yeah, I when I lived in Los Angeles, not a
lot of the housing had air conditioning, which was really weird.
So that's probably my closest to living.
Speaker 6 (02:24):
I think every year it's getting warmer. Every year weep,
we keep adding another air conditioning unit to another room,
so I think eventually we'll have air conditioning everywhere, but
at the moment it's like three rooms.
Speaker 1 (02:36):
Exactly.
Speaker 3 (02:37):
So when you're not talking about air conditioning, you were,
would you please introduce yourself to our users, our users, sure,
our listeners.
Speaker 1 (02:47):
It is It is morning, so I'm only halfway through this.
Speaker 6 (02:52):
So yeah, my name is Debbie. I'm actually living in MAJORCA.
That's why it's so hot. I'm Irish and I work
for Microsoft, mainly advocating for Playwright. So if you haven't
heard of Playwright, then you're in the right place because
that's what you're gonna hear about today. And I've worked
a lot in open source over the years, so many
people know me more in the View and Next ecosystem.
(03:14):
Although I did originally learn Angular JS back in the
day when Angler JS was the cool thing to do.
Speaker 1 (03:21):
It's still the cool thing to do, just in case
you were wrong.
Speaker 6 (03:27):
It's evolved in such an amazing way that it really
has like it's very cool.
Speaker 1 (03:32):
It has, it has.
Speaker 3 (03:33):
I think a lot of people have been surprised coming
back to Angular just with some of the changes that
have happened really since in the last like four or
five versions.
Speaker 1 (03:42):
So but yeah, well, welcome, Welcome to the podcast. So
for our listeners who maybe are not aware what what
is playwright exactly?
Speaker 6 (03:54):
Sure. So Playwright is a way for you to test
your applications. So if you remember back in the day,
some people are still back in that day, when you
build your app and then you have to go and
test it and say, your app has a big form
and you fill in the name, and fill in the
email address, and fill the telephone to check with. The
telephone actually only accepts numbers and doesn't accept letters, and
(04:14):
you fill all this out and then it keeps giving
you bugs and you start fixing them as you go along. Right,
this is such a slow procedure and that's just a
form like imagine your whole website. So people we call
this like manual testing, but the developer is manual testing.
We used to stop on a Friday and say everyone,
stop what you're doing, test the application and then fix everything. Right,
that wasn't that long ago, and some people are still
(04:37):
doing that, So stop doing that. If you're doing that, listen,
Playwright will take that work away from you because you
can basically write a test that automates the browser to
go and do those actions that you would be doing,
such as filling in that form, clicking on those buttons,
putting a product in a cart, and once that test
is written, once you can just run that test on
CI every time you make a change, and so then
(04:59):
you know nothing is going to break or when you
break something, you're not going to merge those changes because
you're going to find that either locally or in CI,
and you'll be able to then fix your code before
you create a disaster. Which disasters are still happening, So
people are not testing their applications.
Speaker 3 (05:15):
Yeah, and there are some tips of barriers to that
as well, you know, to acknowledge that, like sometimes your
boss says, don't do it, and which to me is
always a little like it's counter counter productive.
Speaker 1 (05:28):
But sometimes it's hard. I think we're getting more and more.
Speaker 3 (05:31):
Business buy in to say no, let's go ahead and
testis I think that the value the value add is
not Yeah, debatable.
Speaker 6 (05:42):
I think it's not just the value add. And I
think still it's up to the developer to do a
good job. I provide tests along with their development. That's
just my opinion. I've always fought for that angle because
if the developer doesn't up above, probably are not going
to force the developer to do those extra steps. It's
like accessibility, you add auts your images, you add you
do it automatically as a developer, So write the test
(06:03):
as you go along. But I think as well, it's
not just that people are seeing the value of it,
but testing has become easier, and that means it's using
up a lot less of developers time. Whereas before before Playwright,
for example, testing was it harder to learn, it was
harder to get started with, and people weren't even teaching
it in like you know, boot comps and courses. It
(06:24):
was like just an afterthought. Whereas now Playwright is so easy.
You can get started in minutes and you can like
generate the code just by clicking using say code gen,
which is a tool we have, and it just opened
the browser, start clicking and filling out the forms and
it writes the test for you. So now technically you
don't even have to have any testing knowledge to be
able to write a test. Now, obviously you should have
(06:45):
testing knowledge to write good tests, but you can actually
get started with zero knowledge, and that's that's value. So
any company out there has now excuse.
Speaker 7 (06:55):
Yeah, and you look like you're gonna does Playwright just
instrument the brawl or does it also offer capabilities for
like mobile testing, native applications, those kind of things.
Speaker 6 (07:07):
So we are browser based only, but we can do emulation.
So if you wanted to emulate to mobile device size,
for example, responsibly, things like that we can do, but
actually native you would have to go to say a
BrowserStack for something like that.
Speaker 3 (07:25):
There are other end to end testing so Playwright essentially
kind of fills in that, like end end integration testing
step there are other options on the market. In your opinion,
what sets Playwright apart from those from the other options?
Speaker 6 (07:42):
Yeah, I would say that it is the best because
I work there. I actually I firmly believe that it
is actually just very nice and easy to use, and
I think when it comes to develop experience, that's what
people want. They want a good experience, they want things
to work. We're constantly making improvements and fixes. Everything is
(08:03):
open source, so it's free, there's no cost, and basically
like all the tools that we provide are to help
you be more successful when it comes to testing. And yeah,
I definitely think like just the ease of like getting
started and getting things up and running and using the
tools we have make it, in my opinion, better than
(08:24):
all the rest. But also we're also the newest compared
to all the others, right, so they had to make
mistakes because the JavaScript, the technology wasn't there. They weren't
able to do what playwright could do because we came
along later when I know it's just the perfect time
to build something like this. So yeah, we've been lucky
as well. But also we learned from the others who
(08:46):
did a great job.
Speaker 4 (08:47):
Right.
Speaker 1 (08:48):
Yeah, absolutely, I.
Speaker 4 (08:50):
Love Bla Blaye. Right, I'm a playwright show. I don't
care what people say, but I love playwright because it
makes my life so easier, so much easier. I'm at
a point where I appreciate a tool with a small
subset of scand default, which is play right provice. In
(09:10):
my opinion, I can just write test and then just
write test in a procedural way where I can understand
the test. Right, there's no abstraction. I can make the
extraction that I want, and I love the fixture as
an abstruction layer. But yeah, I can just look at
the test, Hey, go to here, do this, and everything
(09:31):
is a single weight based so.
Speaker 8 (09:33):
There's really.
Speaker 4 (09:35):
Don't arm me, arm me because we used the previous
tool before Playwright, and it was painful, uh to see
the list, especially uh, especially where we kind of like
the front end development uh scene is kind of like
moving toward more silver side rendered, so it's no longer
(09:55):
just the client side, where I think the other tools
kind of like build toward.
Speaker 6 (10:00):
Yeah, which means that you don't have to do like
waiting or think about how long is it going to
take for this to load, how long is it going
to take for this component to be ready to be clicked.
Playwright will just auto wait and retry and that's just
built in and I think that's one of its We
don't even talk about it because it's just that's just
like how it works, right. But people some people don't
know that and are coming from the other you know,
(10:22):
kind of frameworks or whatever where they're like adding timeouts
because they think that's what you have to do, and it's.
Speaker 3 (10:26):
Like, no, oh gosh, we had we had this one
test suite that would take in CI it would take
like over an hour to run because there were so
many set timeouts in it. Because over the years people
are like, oh, it's buggy, I'll.
Speaker 6 (10:42):
Just turn a timeout. Let's not fix the JavaScript.
Speaker 3 (10:46):
I'm like, y'all, you know, like every time this runs,
it has to like you're telling it the minimum amount
of time as to take.
Speaker 1 (10:53):
The minimum is now an hour, and.
Speaker 3 (10:55):
It was so frustrating, And so yeah, we actually have
been moving towards like we use play right now.
Speaker 1 (11:02):
We still maintain other code, other test suites.
Speaker 3 (11:06):
But I think another thing that stood out to me
is how it's easier to get a good selector. It
was really easy to pick really terrible selectors before that
were brittle and you know, unpredictable, and for Angular developers,
like a lot of selectors that used Angular things to select,
(11:29):
which is not a good idea. So so yeah, that
has stood out to us.
Speaker 6 (11:36):
I think as well, that goes back to like before
we didn't change the web that much. We built a
website and that was it, right front end stayed the same,
And now we're constantly evolving and changing. So the app
is getting updated, which means the htmail is getting updated.
The CSS is good at getting updated. And if you
build your test relying on the HTML and the CSS,
then that means every time you change your website, you
(11:56):
got to change your test. So now it's just like
a mess but really you should only test with user
sees and does what they're visible. So like we like,
like you said, Playwright has a better way of choosing
locators because we prioritize role based locators. Now, obviously you
could put test ideas on everything, and that's another great
solutions for a lot of companies because you know they're
(12:18):
they're dealing with so much dynamic data and things like that.
But if you can test closer to the user and
do like get by roll, get by label, get by placeholder,
because the placeholder shouldn't change, that HTML shouldn't change, but
where it's placed on the page might and that's okay
because you're redesigning all the time.
Speaker 1 (12:37):
Yeah, it might not be the second button on the
page anymore.
Speaker 3 (12:40):
And you know, like exactly when you know if you're
getting by text, if your text change, yeah, your test
is going to break. But they should because you want
to be testing that feature. But it's very frustrating if
you're somebody comes in writes a new feature, adds a
new button to the page, and you were counting on
the second button on the page being the one that
you need to click, and now you've got to go
(13:01):
figure out what broke and it's how you don't own
and you might need to get an approval from a
code owner on the other side of the world. And yeah,
it starts to the sort of churn of that starts
to add up quickly. Okay, So I think we last
spoke to you in twenty twenty three. We did math
(13:22):
before we started recording.
Speaker 1 (13:25):
That's fine, time, flise.
Speaker 3 (13:28):
I looked at a calendar, But we had you on
in twenty twenty three, and at that point, Playowright Playwright
was very new in the scene.
Speaker 1 (13:38):
It was sort of just like people were really excited
about it. I know, like our team was, like, we
do we use it. It seems like a lot of.
Speaker 3 (13:46):
Work to change over in those two years. What have
you heard from the community as far as the experience
switching between other test runners and Playwright?
Speaker 6 (14:00):
Wow, in two years a lot has happened in two
years we have. The community has like grown so much,
like so much it's insane and just to see like
the amount, like our discord channel is over sixteen thousand
members and they're so active, Like I don't even have
to go in and help people answer questions because they're
all just helping each other. And that's like amazing. So yeah,
(14:22):
there's there's been so many people in so many stories.
I think when people change over from a different testing
way of testing, it's all about and I mentioned before,
it's just it's just easy, and people are like, this
is fun. Testing has become fun again because and I
think also because easy to learn, but because the tests
work right, and like we said about the locators being
(14:43):
easier and the timeouts not having to be set, we're
having less flakiness. We don't have to clean up tests.
They're isolated between each one, so there's no cleanup needed.
So when people are writing their tests, they're working, so
they're happier and they're like, oh my god, this just
does what it's meant to do, which why didn't do
that before? And I think that's been the big win
for people. Less flakiness.
Speaker 3 (15:05):
Yeah, yeah, I could definitely see that. I also I
remember trying to set up testing, you know, four or
five years ago, and it was always like, Okay, I
got to get to a blog article, I got to
make sure I'm on, Like do my versions matchup?
Speaker 1 (15:18):
Like why is there configuration not working in my application?
Like what's different here? You play that game?
Speaker 3 (15:22):
And it's hard to get things set up. But when
I added play when I added Playwright to an application,
it just worked like it it worked. It was really
easy to get it going. And that impressed me because
there wasn't that I get that anxiety of like, oh,
I got to configure this new thing.
Speaker 1 (15:42):
In my app, and I'm like, how to book right?
Speaker 3 (15:46):
Like how long is this going to take me? It
could take me ten minutes, it could take me three days, Like,
I don't know how long is this going to take?
And Playwright was definitely on the a few minutes side
of that.
Speaker 4 (15:55):
I know.
Speaker 3 (15:55):
There's also, like like child, there's support with NX to
get play right up and running. You knew an angular app.
In NX, you get the option of which test runner
you want to use. It's really easy to set up.
So yeah, and do you do you see a lot
of people or have.
Speaker 1 (16:17):
You noticed people in the community.
Speaker 3 (16:18):
Are people trying to maintain like sort of a hybrid situation?
Are people trying to switch over tests all at once?
What has that experience been like for people?
Speaker 6 (16:29):
Yeah, there's there's everyone has there's all the experiences that
are out there right as in like some people have
to maintain because they just don't even want to go
down that rabbit hole. And some people need to change
all their tests because they're just taking so long in
CI that it's like, right, we need to move, we
need to change Migrating testing is a challenging We don't
(16:51):
have like an easy solution. There's no like magic trick
that you just like because things are different depending on
where you're coming from, they could be completely differ front
and it's like you almost kind of have to start again, right,
which is like painstaking, and you're like, oh my god,
do I do even do this? And like you could
use our tools coche in and go and actually use
the site as a user and build it all again.
(17:12):
A lot of people are using AI to help them
to and again AI is not going to do the
job for you perfect, so you have a lot of
work still to do on that. But having some playwright
tests in there and having some other tests in there
and then saying can you convert this, you might get
ahead of the game a little bit and then it's
just a matter of like tweaking and you know, improving those.
(17:36):
But there's definitely no easy solution, and I think when
people do yeah.
Speaker 3 (17:42):
There's no reason you can't run like two solutions that
the same like in the CI like obviously like maybe
at the same time, I guess there's nothing.
Speaker 1 (17:51):
That happens to me running if something else is there
as well.
Speaker 6 (17:55):
So exactly you could you could have so many this
this part of your side tested by something else, and
this site this part tested by by play right. Like
you know a lot of people mix component testing. They're
not using the playwright component testing, they're using different something else,
and that's totally fine. There's there's so many different ways, right,
But yeah, there's if we could just make wave the
(18:16):
magic one and say everyone change the Playwright, I think
everyone would just pick up that one and go to
the and it'd be all like happy days everybody. But
it's just require a little bit of work.
Speaker 3 (18:27):
Well, and I think there's I know there are you know,
people out there with test suites that they're they're efficient,
they work fine, they're not plakuy like they've got.
Speaker 6 (18:35):
And if they do, you don't need a change and
there's no problem.
Speaker 3 (18:40):
Yeah, Like maybe for a future app, maybe you want
to look to something like Playwright, But there is definitely
value in not always chasing what's new. But then I
also appreciate when a tool comes along where you can say, like,
this is a very painful process for us, how can
you make it better?
Speaker 1 (18:57):
And Playwright seems to sort of fit that, so you
talk a little bit about AI.
Speaker 3 (19:04):
Is Playwright doing anything specifically with AI or is it
more that people are using AI tools to help them
write Playwright?
Speaker 6 (19:14):
That also so, yeah, I mean, obviously nobody wants to
work anymore, right, everyone wants AI.
Speaker 1 (19:22):
To do everything.
Speaker 6 (19:23):
That is the world. I don't think we want to
work before either. Yeah, but everyone ever wants to get
AI to do stuff, and we're living in a moment.
I personally believe we're living in a moment that's very
exciting in the developer world because we get to do
so more and be more more productive, and we don't
have to worry about like those tiny little things and
(19:43):
even just testing. Some people do not like writing tests,
and I get you, I understand you. Not many people
do like writing tests. So to get something like AI
to write tests for you is very beneficial because there
are people out there who are not good at testing,
who do not want to write tests, but they really
should have their application tested, and AI can help them
(20:04):
at least, you know, get started and get ahead of
the game. If you're an expert in testing, you might
be better and quicker than AI, because AI is not
up to the scratch that it should be and will
be at in the future. I'm sure in the future
AI is gonna be much better, but right now, it
never guarantees you one hundred percent everything perfect right. Perfection
doesn't exist in AI, No, it doesn't.
Speaker 3 (20:26):
I feel like there's still a lot of guidance necessary.
And you know, I know there's a lot of anxiety
in the community around AI because you get posts on
Blue Sky that are like it's coming for your Like
your job is gone, you like kiss your retirement goodbye.
You'll never have like you're gonna go be flipping burgers
in ten years, like and that's that's scary for people.
Speaker 1 (20:46):
I mean, like, I don't think they can get AI
to flip the burgers, but.
Speaker 3 (20:49):
Maybe they can. Maybe they can, maybe they can't, And
we just don't know what the limits are yet. But
what I've noticed is exactly what you're saying, is that,
like it's to a good start, I've had to put
in a lot of guardrails in our applications to make
sure that it writes the unit test the way we
want because.
Speaker 1 (21:11):
A lot of the examples that exist that trained the
models that are being used to like to use generative AI,
we're trained on very tightly coupled unit tests and component
tests where it's doing things like clicking the third button
or invoking the very specific component method, and then you know,
(21:33):
like it's they write these tests where you're like, this
is going to be a nightmare to maintain this because
it's always going to like it's brittle, and so I've
had to put in a lot of like, please use
this file as an example of how I want you
to write this test, and it does get pretty close
that you still have to go through and do cleanup.
(21:55):
But what I do like about using AI for testing
is that it does sort of I don't love setting
up tests, m hm, I actually do love writing them
because it's like one opportunity where something literally gives you
a grade. Right, So, like you run your test suite
and you're like, you got one hundred percent covered. That
is an A plus everybody.
Speaker 4 (22:16):
So.
Speaker 9 (22:18):
Good morning. You know that moment when your coffee hasn't
kicked in yet, but your slack is already blowing up
with Hey did you hear about that new framework that
just dropped?
Speaker 4 (22:27):
Yeah, me too.
Speaker 9 (22:30):
That's why I created the Weekly Deaf Spur, the newsletter
that catches you up on all the web def chaos
while you're still on your first cup. Oh look, another
anger feature was just released, and what's this typescript's doing
something again? Look also through the poor requests and changelot grama.
(22:50):
So you don't have to five minutes with my newsletter
on Wednesday morning, and you'll be the most informed person
in your stand up. Ah, that's better. The wiki desperate
because your brain deserves a gentle onboarding to the week's
tech matters. Sign up at Weekly Brew dot deth and
get your dose of deaf news with your morning caffeine.
(23:10):
No hyphe no clickback, just the updates that actually matter
your Wednesday morning soft. Well, thank you.
Speaker 4 (23:16):
How's that type of going, Lara?
Speaker 1 (23:19):
Yeah, somebody to like tell me I'm doing a good job.
Speaker 4 (23:27):
I'm on the uh. I guess the opposite side of
Laura here. I guess probably because I'd like to work
with like deaf tools and provide DX and stuff like that.
I love setting up fixtures for my coworkers and use
things like, hey, how how how to interact with our
mark database? How to interact with this authentication stuff? Right,
(23:49):
you can just do like, uh, do you provide like
a fixture to just do log in or you can
use just uh log in via form and you can
just do a log in by like a third party
service and stuff right, and everything is just very very nice.
And the way that Playwright fixture API is designed, I
love it because you can just hey, this runs, and
(24:10):
after this runs, there's some cleanup to do and you
can do all that. So we completely change the way
that we provide mock data forile application, and the flickiness
is just go from one hundred to like ten percent
because there's there's some some stuff going on. But yeah,
I love it.
Speaker 1 (24:28):
I do agree with you. I do love the whole
fixture thing, like the sort of standardizing processes because.
Speaker 3 (24:38):
There are definitely if you put ten developers on the
same task, you're go get ten different solutions and a
varying efficiency.
Speaker 1 (24:46):
So it is nice to be able to standardize those.
Speaker 6 (24:49):
And that's kind of like as well, what AI deals. Right,
It's like ten different developers and it's going to write
different tests depending on which model you chose, who chose whatever,
But have you have if you started using the playwright
MCP at all?
Speaker 4 (25:03):
I want to ask you about that, I because let's
all all I heard about is they write MCP right,
use this with like some quad that stop app to
pull up an application to do something like a human
would do with like a website. But it never actually
found or not found. But I never explore use cases
(25:26):
for actual development on the testings.
Speaker 6 (25:29):
Okay, so I.
Speaker 4 (25:30):
Would love to learn about that today.
Speaker 6 (25:32):
Okay, So what I'm going to tell you is basically
just me playing around with things. And I'm not saying
that this is the way you should write tests and
drop everything else on this is it. This is just exploration.
And then when playwright MCP is like three months old,
maybe four months old, so it's still all very new
and we're still learning, but it's it's in my opinion,
it is a better way of writing tests because it
(25:54):
gets things closer to the truth. So what the playwright
MCP does is once you've set up your MCP, you
can then get you really have to work on the
prompt file, right. It's very important to prompt and to
guide it towards the right direction. But basically what you
can do is ask it to navigate your website. It
opens the website and you can actually say to it,
(26:15):
give me some ideas of what to test on this website,
and then it will actually go along and start looking
at your website. It takes a snapshot, an area snapshot
of your page, so it can see what's on the
actual website, and it can see it has a search feature.
It sees it has a theme toggler, it sesar, has
a log in. So it will say, for example, oh,
(26:36):
I see you've got a search feature. That's a great
thing to test. And it will then start searching for
whatever it is. So I have an example on a movie. Yeah,
it will type in a movie. It will then say, okay,
I typed in the movie. Now I see there's a
filter by popularity. It will start filtering that by the popularity.
It will do all these actions, but then it will
have in its memory and in its context everything it's done,
(27:00):
and from the page snapshot, it's got these refs, so
it's able to then go back to them and say, oh,
I know that this is a get byroll placeholder search.
And so it writes the test much more closer to
the actual user, because it's like it's real rather than inventing,
rather than you know, looking at test files and making
(27:20):
sure that previous test file or the source code was good.
Maybe you don't even have access to the source code.
You don't need it because it's actually clicking doing like
a user would and then it's from its memory writing
down and writing and creating that test based on what
it just did. It's very fascinating. It's very exploplorative, and
I A lot of people are using it and doing
(27:41):
great with it. Some aren't. That depends on your website,
It depends on what you're doing. It's it's I think
it's great because it does actually do some really good
things if using test ideas, though it doesn't have access
to the test ideas, so that's something that you know,
we could definitely work on and improve. And for assertions,
I think it is a better job with assertions, but
(28:02):
if you guide it to the right way, otherwise it
might just do like to be visible all the time
because that makes sense to it. Maybe that's enough for you,
Maybe that's all you want, and if not, you kind
of have to say, like you know, use this instead
of make sure you add to have count if there's
some you know, and guide it along those ways. But
it's very powerful, and I think we're in such early
(28:23):
stages that I just I can see it not being
the perfect solution right now, but I can definitely see
it being an amazing solution closer in the future. To
improve just people's testing. Like sometimes you go to a website,
like what do I test? You don't want to test?
Get a eie to you know. It's like saying me
saying to you, chow, can you test my website?
Speaker 1 (28:44):
Right?
Speaker 6 (28:45):
You would you would click the button that I would
never have clicked, and you will find the bug right.
And so getting a eye to do that for you
is helping you.
Speaker 4 (28:56):
Yeah, yep. I used playwright MCP in my daily life
for I have like a live style, live real life
thing project where I where search for the instaurants and
stuff like that. I'm in the process of like moving
to a different stage as well, so I have play
RYMCB just go through all of these websites and things
(29:16):
that like normal web search tool by these AI lms
that cannot do but can do it. For example, I'm
interested in what direction the house is pointing. Yes, lams
cannot do that. But then play I can actually pull
up and see the snapshot of the of the satellite view.
Speaker 8 (29:39):
Nice.
Speaker 3 (29:40):
Yeah your home search like this is brilliant that I
was Yeah because yeah state and so it's not like
you can just go drive by the house.
Speaker 4 (29:53):
Exactly and I can ask all kinds of questions. You
you don't you can't believe you have to try it
if you look for things, right, So like, okay, we yeah,
we are interested in these zip codes. We are interested
in going to these locations we know ahead of time,
like oh there's Asian grocery market down this way? How
long does it take?
Speaker 1 (30:14):
What time?
Speaker 4 (30:16):
And just figured it out like what And the playwright
it really really helps him because it's just as simulate
an actual human going through these websites.
Speaker 1 (30:25):
Oh that's fascinating.
Speaker 6 (30:28):
You have to write a blog personal at show.
Speaker 1 (30:31):
Absolutely like that's amazing. Realtorms everywhere just.
Speaker 6 (30:35):
Like yeah, yeah, I mean think about it, like it
could do a lot of cool things for improving just
finding the right house.
Speaker 3 (30:45):
Right.
Speaker 6 (30:46):
I actually bought a table for my children on it
because I wanted to find the cheapest price. But I
also you know, and like some websites don't tell you
how much it costs the shipping until like you fill
out all the details. And that's like, so time.
Speaker 1 (30:58):
Consumed three times more than the table exactly.
Speaker 6 (31:01):
So so I got the play right MCP to do it,
and then it filled in okay, obviously mock data just
to get to obviously it knows where, you know, I
put in where I was going, where I live ish,
and then it was able to say, right, it's going
to cost you thirty euros to shift there, So now
I knew the price is this plus this. But I
also found a deal that if you bought two chairs
with the table, it was actually cheaper, whereas I might
have I might have found that. I might not have
(31:23):
found that, but I wanted to search, and it's like
it just did it for me, and you know, that's
the kind of beauty.
Speaker 4 (31:29):
So yeah, it definitely makes my life a lot easier,
especially with the baby. We just we just bought a
stroller with AI recommendation.
Speaker 3 (31:41):
Honestly, this is quicker the reviews because it's like it's
hard to parse through reviews on things to know like
we need to get a carpet cleaner, like we just
need we have carpet now, and I would like to
clean it because it probably grows, but I don't I
don't know which machine is going to hold up, and
I really don't want to buy one every six months.
Speaker 1 (32:00):
And so, but you start reading reviews and you're like, Okay,
I guess I could.
Speaker 3 (32:06):
Read all twenty five of these, but it would be
nice to just have ai be like, Okay, I went
to all twenty.
Speaker 1 (32:10):
Five and they're all saying yeah the one yeah, Like, also,
is it is Bissell doing this review, because maybe that's
not going to give me a like a balanced fair review.
You know, Yeah, that's awesome. I also I did want
to come back.
Speaker 3 (32:25):
That'd be to one thing that you said that I
really think is important, whether you're using the Playwright MCP
or not, is that your integration and your end end
tests really should not know your code implementation, and if
it does know your code implementation, that is.
Speaker 1 (32:43):
How you've set your code. That's how you've set those
tests up to be brittle. So I think that's a
very important point to call out. Okay, so talk a
little bit about AIU, the MC and the MCP server.
Is that's is that in developer preview, is it like
is it ready to go or people? I mean obviously
(33:04):
Chow's using it. Can you just can anyone use it
at this point?
Speaker 4 (33:08):
Is yeah?
Speaker 6 (33:09):
I mean everyone's already using it. We were like the
number one MCP server for ages, and like it would
just took off of just like crazy.
Speaker 1 (33:18):
Or anyone else was doing it, which is kind of
you No, not if not.
Speaker 6 (33:21):
Before, but it just like because it because because we're
browser automation and it just is not just testing. That's
the thing like Chili's had. It's you know, if it
was just testing, we'd be in a smaller market, right,
But because it can be used for so many other things,
it's like, wow, we can do all this other stuff
that you know you didn't think you could do, you.
Speaker 3 (33:38):
Hard thing, right like you like this is this is
the dream? Like I if I maybe I should see
if it can go to me.
Speaker 6 (33:45):
It can't clean your carpet, you know what I would
love it to do though, is.
Speaker 1 (33:49):
Like help me write my stupidio tickets. But anyway, I
bet it could and.
Speaker 6 (33:55):
It definitely could. Yeah, Like it definitely could. And then
because it's a browser, like you can actually like take over.
So when I would like do the table I was
in that browser state of like payment, I could then
just go in edit the address, click on the PayPal button,
then continue the process. Right, And that's the kind of
cool thing that you can like interact with it because
it is just a browser. But yeah, like AI is,
(34:21):
it's definitely something that I think everyone should be investing
some time into just experiment and learn what is out
there and what it can do, because it can, in
my opinion, help you a lot in your journey, whether
that be testing or whether that be whatever else you're doing.
But we also have some AI features in debugging, which
is also another painful thing that developers have to do,
(34:43):
is debug test, especially when they're not your tests and
like all of a sudden you've taken over this test
suite and like it's failing. You're like, oh my god.
So we have a couple of options for you. Again,
it's AI. It's not perfect, but it's very very good,
and it's a great starting point. So there's fixed with
AI that's right in vs code. So if you run
your test and it runs into an error, there's a
(35:03):
little kind of star kind of magic icon, and if
you clicked that, it will read the context that we
have put in there that AI reads. It's just for AI,
and it's basically giving you the page snapshot and a
couple of other things so that it can make a
good and better judgment of how to fix it rather
than just asking, say Copilot, without this feature, it wouldn't
(35:26):
have as much context. So this is in vs code,
it's in a couple of places where you can click
that button. And then we also have something very similar
which is in the UI mode or in trace viewer
or in the HTML report. So if your test BAIL
and CI, you can open up the HTML report, your
trace viewer and you can click the copy prompt button
(35:46):
in the error message of your test or in the
HTML report. In the error message, if you click on
copy prompt, you copy a prompt over to whatever LM
you're using via vs code and Copilot, via whatever cloud desktop,
whatever you want. Paste it in there, and this prompt
has your test source code has a page snapshot. It
might if you've set up your confict. It has a
git diff, so it knows what's changed recently in your
(36:08):
in your gitdiff, and then you paste that in and
it will then make a good judgment of like why
this failed, what happened? And the majority of time it
is a really really good job. Now there might be
something that's really difficult to debug, and then it might
kind of have to go, oh my god, I don't
know what's going on here, and might suggest some things
that aren't perfect. But in general, for me, it's saved
(36:30):
so much time because it's like, oh, this doesn't work,
click a button, fix it AI, fixed on review everything, Okay,
Always check because sometimes it might just make the test
pass without actually having done a good job. So always
human the loop always, but definitely do try out the
fix it AI and coffee prompt buttons because I do
find them very useful. I hope you do too.
Speaker 1 (36:52):
Yeah, that's that sounds amazing.
Speaker 3 (36:54):
I think one thing that you said to you that
I wanted to come back to is basically like we
should like probably everyone needs to be embracing AI at
this point, And I've had this conversation with a lot
of people because there are a lot of people that
like I.
Speaker 1 (37:11):
I don't want to give up certain parts of my
job because I like those parts of my job.
Speaker 3 (37:16):
But at the same time, if I don't understand AI,
if I don't understand its limitations. So like, as a
leader on my team, I need to know what the
playwright MCP is good at doing what it's not good
at doing. I need to know what fix with AI
is good at doing what it's not good at doing.
Because whether or not you're using it in your daily practice,
there is going to be an intern or a junior
(37:36):
or a mid level developer on your team that is
using it, and they're going to be using it heavily.
Speaker 1 (37:42):
And if you don't know what patterns to sort of
look for, you know, it's like if anyone's.
Speaker 6 (37:49):
Using it is basically and I say the same things
as you say, but I also want to say it
a little bit different because sometimes people think everyone's just
telling me I should use use AI because the junior
is going to come and take my job. I actually
think that we as humans live in fear of change.
And I even remember, like you know, the iPhone when
(38:10):
it came out and FaceTime came out, and the thoughts
that somebody would call me and see me a video
of me in that moment was the scariest thing ever.
I was like, oh my god, I'm not even answering
their call. I'm gonna see me. I could be in jamas.
I'm not ready. I hadn't done my hair right now,
I'm facetiming all the time. It's like my kids know
FaceTime like it's the first thing that they ever see,
(38:32):
because that's the only thing the phone does in their opinion,
because they don't watch TV or anything like that. But
face time is like, we just embraced it, but a
lot of people fought it at the time. A lot
of people didn't are worn't ready for the change. And
that's where we're going with AI. And I think just
in general in life, we fear something that we are
we don't know. We fear something that is moving faster
(38:54):
than we can even imagine and keep up with. So
that's something that's very very hard to deal with. And
us being in the jobs we are in sometimes we're
much more ahead of everything than the normal person in
the normal life. So I would say try it out
(39:16):
because it's it's something that is going to help you.
And if you think it's not right, just like when
I said everyone you should use static sites, and you know,
people fought me on that, and I said of tailwind,
and people fought me on that. People always fight change.
I've lived this while after so long, try it out.
And if you think that AI is not going to
(39:37):
help you, well, make sure you have a good reason
to actually say, you know what, I've used a AI
and I've written tests with it, I've written code with it,
but it's always done a terrible job. And I'm faster
and better than perfect. But you've spent twenty hours doing whatever.
All right, But don't be the person that says, oh, no,
I'm afraid to use it. I'm not gonna use AI.
(39:57):
I don't like AI when you haven't used it. It's
like someone say they don't like tail and CSS and
have never used.
Speaker 1 (40:02):
It yeah, Or they don't like chocolate because they've never tried.
Speaker 6 (40:06):
It yeah, or even angular in view right, and they say, oh,
I don't like anger, I don't like view but I've
never used one of them. It's like, no, use them
and then make up a decision. So, yeah, I definitely,
but it will help you, it really will, I promise you.
Speaker 1 (40:19):
Yeah, And I and I guess I would. I would.
Speaker 3 (40:21):
What I was saying too is not as much as
the junior developer is going to come for your job,
but it's more like the judor developer is going to
mess up your code.
Speaker 1 (40:32):
But you know, I think as you'd be all right.
Speaker 3 (40:36):
I think to like in the in the tech community,
we we've had the fire drill before where everyone's.
Speaker 1 (40:41):
Like everyone's doing blockchain and we're all going to do
it forever and it's the best thing in the world,
and then we're all like okay, but like it's very
specific and not everybody.
Speaker 6 (40:49):
I never believed in that though. I actually never have.
I never went down that route and I really didn't
think and I yeah, like.
Speaker 1 (40:56):
There are people that are like they're still like they've
been hurt before, Like we've all been hurt before with
the new thing that's coming. But I feel like AI
is it's different.
Speaker 3 (41:06):
It's different, and it is sort of one of those
moments where you're either kind of on the train or
the train is leaving you behind, and maybe you're gonna not.
Speaker 6 (41:14):
I don't think you will actually be left behind at all.
AI is gonna scoop you up. You're going to get
you on that train. You might just be in the
last carriage, but you're going to be on that train
because it's it's in everything now and you know, the
more and more companies are building agents as part of
their workflows. We're going to be booking flights using AI agents,
and the developers that work for those companies are going
(41:36):
to be building and it's going to be very exciting.
And it's like, think about the cool things that you
can do as developers and even bring into the company
that you can think about how can I use AI
in the company and how can we improve our client journeys?
And if you, as a developer, can think about that
and embrace AI and make this happen, we could just
have so much easier worlds.
Speaker 1 (41:57):
I think sure, and I do agree. I mean, I
definitely I was. I was hesitant for a long time,
and I've.
Speaker 3 (42:05):
Actually, you know, I've found some stuff that's good at
that I like to use it for where it's made
my genuinely made my daily existence at work an easier situation.
Speaker 1 (42:14):
And now I'm going to try the playwright MCP because
we have a whole bunch of like tests we need
to write and it'd be really super great to get
them done fast.
Speaker 6 (42:21):
So even just get it started, even if you have
to refactor something, but to get started like bang.
Speaker 3 (42:27):
Yeah, yeah, exactly, I could totally see to a use
case where you're like, hey, here's a bug that I got.
Speaker 1 (42:33):
Can you help me write a test that will make
sure this bug doesn't happen anymore?
Speaker 6 (42:37):
Exactly, test some edge cases out. It found some edge
cases in my search feature that I never even thought about.
I was like, oh my god, and I actually I
need to fix the search feature now because I found
something that doesn't actually work.
Speaker 1 (42:48):
So it's I mean, it's something that work.
Speaker 6 (42:51):
Yeah, but it is cool. It is cool. It's it
brings a lot of value and you just have to
find the value.
Speaker 1 (42:59):
Yeah. Absolutely. So one other question I had for you.
I know that Playwright this is changing gears.
Speaker 3 (43:07):
I know that Playwright had a component story or component
testing story at some point.
Speaker 1 (43:13):
Where does that sit today with Playwright?
Speaker 8 (43:16):
You know what?
Speaker 6 (43:17):
It's kind of sitting. Unfortunately, there's been a lot of
development in the AI world, so we've been kind of
like forces of being pushed towards you know that, and
then just maintaining Playwright in general. So there hasn't been
enough people on the team to be able to dedicate
to component testing. So I don't really know where its
future is going. And I really don't want to make
(43:38):
false promises, and I don't want to say anything that
I shouldn't say, so I would say, just follow the
get up issue that's out there where everyone has been
kind of you know, commenting on, and the team one
day will make a decision to either you know, put
priority into it or deprioritize it completely. I have no
idea because we're just we're a team of very small team,
(43:59):
so it's everyone's everything, and it's so difficult to get
everything done. And I think if you're gonna do it,
you need to do it properly, and you need to
really like dedicate and make sure it works on every
single framework, not just ANGOD like on everyone. And that's
that's hard because frameworks keep changing, things keep happening. So yeah,
it's it's not an easy thing.
Speaker 3 (44:19):
Do you feel like though there would be a future
so I know that like when component testing sort of
that was you know a few years ago people that
people were talking about it a lot because tests like
integration and end of the end test suites were expensive
to run and ci they are harder to maintain.
Speaker 1 (44:38):
Do you feel like Playwright maybe negates the need for
that layer of testing or do you still see value
in it?
Speaker 6 (44:46):
I personally think it depends on your application, but also
I would I don't even write you a test anymore
because I don't I'm not writing the specific component that
really needs that kind of testing. And maybe you maybe
it's a shopping cart type of component that like really
needs to be heavily tested, and that that makes sense.
But in general, I just find the end to n
(45:07):
testerl I call everything end to un tests, even though
you might call it integration tests. I just put all
the same booking the person who's like, yeah, it's not that,
yeah exactly, but I think I think that they bring
more value than unit tests. Again, depending on the application,
depending on what you're doing, and I would always end
to en test first. And maybe you're developing component and
(45:29):
you need that specifically, but if you're developing a component library,
it makes sense that you write unit tests because that
component is going to be used in different websites and
for different reasons. So I've done a lot of that
in the past. But yeah, if you don't have time
to test everything, I would put end to end tests.
I would use Playwright before component testing. And that's I
think why we invest more in into end testing, because
(45:52):
it makes more sense than you know. Components at the
end of the day could be very well tested, but
when you put them together, what happens that's the real
important part.
Speaker 3 (46:02):
Your user doesn't really care if your unit test paths
on your cart component, if your car component doesn't work
with everything else.
Speaker 6 (46:09):
So exactly, And and I will like to say, and
I think VAT is doing a great job in the
space of like for component testing, and I think you know,
if you're already using that, then you don't need to
change or do anything else, but definitely into a test
and make sure they all work together.
Speaker 3 (46:27):
Your small team and obviously working with AI. Is there
any other features that your team has been working on
that you're excited about or is there anything about the
MCP server or the other AI features that we haven't
talked about yet.
Speaker 6 (46:42):
I think like we're always trying to improve things and
you know, move things along in the direction that the
user wants. There's a lot of which trying to do
a lot of stuff and it's really hard, but it's
it's like, where does AI fit into our story and
how can we improve people's lives when it comes to
test in the AI world, you know, and a lot
of people in the past we're using like cucumber and
(47:04):
wanted cucumber integration. We don't have that. But now my
question to anyone out there is, doesn't make sense for cucumber.
Can we do something with LMS, maybe with the player
at MCP that could bring in that kind of cucumber
side of things and you know, using natural language, start
creating better tests. How can we get the MCP server
(47:24):
to make sure it's writing better assertions? And I think
there's a lot of a lot of things that we're
working on but testing out that might just go thrown
in the bin and never be seen by the public
because it just didn't work because we don't know, and
every possibility is out there is just like we just
keep coming up with new ideas. It's like, oh my god,
you can now do this, Like MCP servers are like
(47:46):
eight months seven months, right, it's all so new. So yeah,
we are testing and working on a lot of stuff,
but nothing specifically that I can share that's like, oh
my god, we're gonna you know, we're going to change
your lives. I would say, just keep it watching the
Playwright channel because we do, you know, keep the people
up to date and throw things out. I keep creating
(48:08):
videos that are telling you. You know, you can generate tests,
you can get a playwright MCP service to explore the website.
You can use it just a browse browser, automate stuff.
And the more we invest time in it and and
kind of like play around with it, who knows what
we can do next month. We don't know, you don't know.
I'm listening to the chat story going, wow, that's a
really great idea. Maybe, you know, maybe we should work
(48:30):
more towards that. Yeah, there's so many cool things. A
lot of improvements have been happening in the HTML report
and trace viewer. Coachen as well can now generate assertions.
Speaker 7 (48:41):
So this, you know.
Speaker 6 (48:42):
One of my thoughts is how can we mix the
MCP and co gen together, right, I think like there's
a lot and I don't I don't even know if
the team are thinking about that, but that's something like
cochin is great. Yeah, NSP server is great. How can
we make everything great? How can we put the trace
viewer in there so we get open up the trace
viewer and deeper get self properly. Like there's I don't
know what we're doing. We're just we're playing around with things,
(49:04):
but who knows. I'm not even saying we're doing that.
I'm just saying these are things that to me sound cool,
but I don't even know they actually have a good
story or not.
Speaker 1 (49:13):
Yeah.
Speaker 3 (49:13):
Yeah, I think that's part of software engineering too, is right,
like you're you identify the problem, like this is a problem,
and then it's like, all right, how can I solve it?
And there's so many different ways things can be solved?
And I mean there, I think there's a lot of
processes in my daily life that I just accept.
Speaker 1 (49:29):
I'm like, whatever, this is just the annoying thing I
have to do to do.
Speaker 4 (49:32):
X, Y or z.
Speaker 1 (49:34):
Where there somebody Chow will come along and be like
that is annoying. I am going to automate that, you know,
And so it's nice. That's what I love about the development.
Speaker 3 (49:42):
Community, speaking specifically, because Playwright is open source and there's
a huge community supporting it.
Speaker 1 (49:49):
What does Playwright need from the community at this point?
Speaker 6 (49:53):
I would say, like the community is amazing, and I
really do appreciate all community members out there and all
the MVPs and ambassadors who are doing trip end of stuff.
So they've taken a lot of the work away from
me where I was the only one speaking at the
conferences and doing stuff. So now it's like, wow, we're
being represented everywhere and blog posts written, books written, and
that's I really want to say thank you because that's amazing.
(50:15):
So I would say the best thing that the community
can do is give us feedback. Don't be afraid to
share stories and tell us this is working great. You know,
even even when, especially when it comes to AI, right
a lot of people don't like it. Great, Well tell
me why you don't like it and what didn't work
and how we can improve that and make it better.
Share your ideas with us, create feature requests, file books.
(50:38):
That really helps us as well. But definitely like how
can we improve what because we're imagining what you need
to do, but sometimes we don't actually know what you're doing.
So maybe tell us like, this is what I'm trying
to do and this is the feature I need to
do it and around AI or around not AI whatever,
because we learn from those stories. So yeah, feature requests,
(50:59):
but reports, and just reach out to me and say, hey,
we're trying to do this. I'm trying to do this
and I don't know I bring all that back to
the team and say, hey, I had this great conversation
with this person and they're trying to I don't know,
run all these tests using blah blah blah and doing
blah blah blah. Like, yeah, we need all those stories
because otherwise we just focus in one area, right, we
(51:20):
need to broaden it out.
Speaker 3 (51:22):
Yeah, definitely. And so you've mentioned that there's a discord
server for play, right. Are there other ways that people
can communicate with you or the team?
Speaker 6 (51:33):
GitHub is our main source if you want to like
speak with engineers and you know, get your feature ideas
and things like that there. Getthub is the best place
because everything's out in the open and it makes it
you know, people can upload it and then we kind
of understand is this something a lot of people want
or just a small amount of people want? So it's
really important really one team or is it like one
hundred and fifty thousand people. I was like, oh my god,
(51:54):
we need to do this. And then LinkedIn. We're also
quite active on LinkedIn and on YouTube as well. We
have a very good YouTube channel where we post videos
quite frequently. I'd say, and I mean, we're still hanging
out there on X. You know, we're not great, but
we're kind of there because you know it's not great,
but definitely LinkedIn YouTube and discord and getthub. We're also
(52:19):
on Blue Sky, but we're not really we're not really
fully there either, but do follow us on blue Sky.
Oh and Depth too as well. Sorry grab blood past.
Speaker 1 (52:25):
Yeah I do.
Speaker 3 (52:25):
I do love Blue Sky for the community, but I
had I think once I cut X out of my life,
it's been hard to kind of go back into that
lifestyle of being.
Speaker 6 (52:37):
Tweeting social media.
Speaker 3 (52:39):
It turns out my life is better without social media.
Like when I delete alaces, it was like the best
thing that ever there's been.
Speaker 6 (52:46):
So it's called life.
Speaker 4 (52:48):
I don't like.
Speaker 1 (52:48):
I just got my cousin ping me last night, was like,
have you been involved in this drama? And I'm like,
I didn't know what's happening, and up until it's.
Speaker 6 (52:55):
Like the news, I don't watch the news, and like
then my husband's like, did you not know in America
that I'm like, I have no idea, you know what,
I don't care because I'm living my life and my
life is pretty cool and exciting. Sorry everyone else.
Speaker 1 (53:07):
Yeah, no, it's there. That's a whole other episode that
we go what's happening in the United States.
Speaker 6 (53:17):
Anyway, I'm having kids. Is a great way to get
you off social media as well. You just don't have
the time to share anything with anyone or read anything
or care about anyone else because your time is just
focused in whenever.
Speaker 1 (53:26):
But yeah, exactly, exactly. Well, I want to thank you
so much for taking the time to join us today.
Speaker 3 (53:34):
I am very excited to go test out the MCP
server honestly at work because I got some tests to write.
Speaker 1 (53:42):
So let's see how this movement throw some see what happened. Yeah, definitely,
and yeah, I'm excited. How Like I love your house
searching story. That's fantastic. I'm like, hmm, like I'm now
I'm imagining all sorts of things. So yeah that my
little developer brain is like, well.
Speaker 6 (54:02):
I'm a vibe vibe coded Oh just sit there and
vibe it.
Speaker 3 (54:08):
I But Debbie, thank you so much for joining us.
We appreciate very much to taking your time to your team.
I want you to please give them our heartfelt appreciation
for all the heartwork they have put into Playwright, for
the features they've given us.
Speaker 1 (54:27):
It is a great solution.
Speaker 3 (54:29):
It has been really a change in the way a
lot of teams are handling that layer of testing, so
we really.
Speaker 1 (54:37):
Do appreciate all the effort that you and the team
have put into that and to our listener.
Speaker 3 (54:45):
If you would like to subscribe to the podcast, you
can get more content like this every week delivered to
your phone. N g coomp will be October seventeenth and
eighteenth in Baltimore, Maryland. If you have not bought your
tickets yet, it is time to do that, so get
your tickets, get your travel arranged.
Speaker 1 (55:06):
We'd love to see you there and we will catch
you next time. Bye bye.
Speaker 8 (55:14):
Hey, this is Prestol. I'm one of the NGI Champions writers.
In our daily battle to crush out code, we run
into problems and sometimes those problems aren't easily solved. Ngcomf
broadcasts articles and tutorials from nngie champions like myself that
help make other developers' lives just a little bit easier.
To access these articles, visit Medium, dot com, forward Slash, nngcomm.
Speaker 2 (55:36):
Thank you for listening to the Angular plus show in
Chicoff podcast. We'd like to thank our sponsors, the ngicoff organizers,
joe Eames and Aaron Frost, our producer Gene Bourne, and
our podcast editor and engineer Patrick Kay's. You can find
him at spoonful ofmedia dot com.
Speaker 9 (56:00):
I didn't think