October 24, 2024 • 44 mins
The illustrious and well-regarded Gil Fink joins the Adventures in Angular panel to talk about profiling your Angular apps. Profiling consists of finding bottlenecks, and memory leaks among other problems within your application. Most of the time, the problems are hard to see from the development side. Usually, they appear when your user uses a device that is slow or a connection that is faulty. Gil explains how to find and fix them.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Links
Picks
- Gil - Follow Gil on Twitter > @gilfink
- Gil - Wokwi https://github.com/wokwi/wokwi-elements
- Gil - Star Wars The Clone Wars
- Alyssa - BundleSize.dev - Analyze and Benchmark your JavaScript and TypeScript
- Shai - FREE WORKSHOP - The Roadmap to Angular Testing Mastery
- Shai - https://www.ng-conf.org
- Younes - Reactive Extensions for Angular
- Chris - Eero
- Chris - @GrumpySkeletor
- Brooks - LoopBack 4
- Eddie - Animal Crossing
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hello everybody, and welcome to another episode of Adventures in Angular.
I'm Shy Wrestling from testangular dot com and today we
have our panelist from the Order in the Zoom Chris Ford.
Speaker 2 (00:21):
Hello, Hello, Eddie Hingele everyone, Uns, j D Hello, Alisa
and Chell Hello Hello.
Speaker 3 (00:30):
And Brooks Force sure hey everyone, and today we.
Speaker 1 (00:36):
Are hosting a very good friend of ours and also
Angular canon, which means a very good developer.
Speaker 4 (00:45):
Gil think he everybody nice to be here.
Speaker 5 (00:49):
Nice?
Speaker 2 (00:50):
So Gil first of all introduced yourself, not to us
because we already know you, but to all the listeners
who might not know you.
Speaker 4 (01:00):
Who are you?
Speaker 2 (01:01):
What have you been doing this afternoon? And what's up
in general?
Speaker 4 (01:06):
So I'm Guil think I'm the CEO of Sparksis. It's
my own company. It only have one employee me myself.
Speaker 2 (01:15):
And Night, so you're also the janitor.
Speaker 4 (01:18):
I'm also cleaning the house because as a freelancer, my
house is my office. So of ten years of Microsoft
Most Vulnerable Professional GDE, you will developer expert in web
technologies wrote a book that you can find in the
(01:40):
Amazon called Crow Single Page Application Development One kevit with
the book it was written into twenty fourteen and it's
in backbone.
Speaker 6 (01:51):
So anyway, you've only written one book. I thought you
had like a like a library of books.
Speaker 4 (01:58):
I wrote a book, but I also wrote a few
Microsoft Official courses that were learned in Microsoft Official you know,
some learning centers all over the world, so things like
HTML five, programming, working with the apps in Windows eight,
and et cetera, et cetera. Should I say, writing Windows
(02:22):
apps And that's all. I'm also helping in organizing conferences
like Angler up and React next in Israel, so you're
very welcome to come to Israel someday when this Corona
crisis will end.
Speaker 6 (02:40):
Nice.
Speaker 2 (02:41):
And also you organize the Javaskirt Israel meetup group.
Speaker 4 (02:46):
I'm one of the organizers. I can say that I'm
organizing all the meetups. But you're managing the content team,
and I'm in part of the content team. So yeah,
this is.
Speaker 2 (02:58):
How I knew that. Okay, So thanks, And so today's
topic is about profiling, right, so it will be amazing
if we'll talk about first the problems that we need
profiling for to solve, and then you could take us
(03:19):
through a.
Speaker 6 (03:19):
Journey maybe, like let's first talk about like what is
profiling like what is what does it given me?
Speaker 4 (03:26):
So think about yourself as a CSI guy or a girl,
and the idea of profiling is to find problems problems
that you might have. But if we're talking more exactly
about development, then most of the time when we're talking
(03:46):
about profiling, we're talking about profiling or finding bottlenecks, memory leaks,
and things like that. So we are trying to understand
problems that we have in our software, and by finding
those problems we and solving them, we may improve the
(04:08):
performance of our application, either with the memory consumption of
the application or how fast we ship frames to the screen.
Speaker 2 (04:20):
Also, so that's an amazing analogy. Okay, we're a CSI
team here. Okay, people, now, now we have a problem
where we are in the crimes and what do we see?
What are the problems that we need to profile.
Speaker 4 (04:36):
So most of the time, when we are not seeing
the problems, we will find the problems by our users.
What I mean by that, most of the time when
I'm coming to companies, I'm coming and helping as a
consultant because the users are renting about bad performance, either
(04:58):
because they used app in a device with slow CPU
or they use your your app in a web browser,
that is in some you know, mobile phone or tablet
or whatever, and they're complaining that things aren't working, things
(05:20):
are creaking. You have junk with a not with you,
meaning that when frames are shipped to the screen. We
have a screen rate of sixty frames per second, and
if you go below that frame rate, then you will
have quirks in your animation, in your UI, in everything.
(05:44):
So the idea is to make your patients fast and
fluid and that the users won't complain. What I'm suggesting
mostly for companies is to add development in the development cycles.
Also performance or should I say profiling or performance cycles
(06:05):
means that add those cycles to the development phase and
not to the you know, maintenance when when the users
are complaining, find the problems before they are created?
Speaker 2 (06:19):
Wait, how do you do that?
Speaker 4 (06:20):
How do you do what?
Speaker 6 (06:22):
How do you how do you find the problems before
they're created?
Speaker 4 (06:25):
As I said, add pro filing cycles to your development phase.
What I mean by that is but okay, So the
idea is as following you can take There is a
profiling process that is very very profound. What what you're
(06:45):
doing that process is the following You establish some baseline.
That means that you're creating a branch to your application
or something like that, and you're working in incognitum mode
for example, not affect the performance of the application by
outer means like extensions in the browser or things like that.
(07:09):
After you establish that baseline, you start the profiling process,
which is the process is collect the data. You're collecting
the data using probably your developer tools from developer tools
Firebag in Mozilla or whatever you like. You collect the
data using those tools, and then you analyze the results.
(07:33):
If you're analyzing the results and you find some problems,
and you will find problems probably, then you tune up
the application. What I mean by that you try to
solve the problems, the bottlenecks that you find by adjusting
your algorithms or thinking about how to improve the loops
(07:54):
that you've created or things like that. Once you finish
tuning up the application, test and measure. You test if
the tune up worked or not, and then you continue
on collecting data, analyzing, tuning and testing and measuring. Then
this is the profiling process. That process helps you to
understand how if there are bottlenecks or performance problems, and
(08:20):
then find them and probably or should I say, hopefully,
solve them before they are shipped into the world of
your users.
Speaker 3 (08:32):
And maybe you're going to talk about this later, but
how would you integrate this in your continuous delivery or
continuous integration? Which parts could be automated? Which parts? Which
part would you recommend to automate or to not automate
or just let's not care about automation.
Speaker 4 (08:51):
I'm carrying about automation, and that's a good question. Unfortunately,
most of the tools that we are using to file
applications are the developer tools. You can do that through puppeteer,
but I don't think that there is a solution that
automates this process, okay, or most of the time when
(09:15):
you're doing that process, it's manually. And that's an idea
for finding or tracking things. Maybe someone who listening to
us will take that globe that you throw it my
face and start thinking about how to add profiling processes
in CI. That's an interesting idea. Have you learned or
(09:41):
do you know a tool that is doing that?
Speaker 3 (09:43):
No, really, I know that there's a way of adding
lighthouse to your CI. Never never dived into that, but
I think it's going to be limited. It's going to
be just some monitoring, not real profiling and aware of anything.
Speaker 4 (09:58):
Lighthouse is cool and I'm using it a lot to
start finding problems, but the real problems you won't find
with Lighthouse. You will find how many HTDP requests your
app or your web pages are doing, and some suggestions
of how to to make image optimizations or other stuff,
(10:23):
But the hardcore bottlenecks you won't be able to find
with Lighthouse. So this is not an ideal tool for that.
But I know that you can add Lighthouse to your
your CI and monitor static, monitor your web pages, or
(10:44):
your way back.
Speaker 6 (10:46):
So it's like Lighthouse is a way to get started,
but it's not a way to like find the deeper issues,
is what you're saying.
Speaker 4 (10:54):
It's when we're talking about deeper issues, we need to
understand how things are working in the browser, and for
that when we need to understand how pixel pipeline is working,
and how where the browser is shipping the frames to
the device screen, and what should we do in order
(11:18):
to increase performance or what should we avoid in order
to increase our web page performance.
Speaker 7 (11:27):
As a scenario for you, and it may or may
not be based on a true story. Say I'm working
on a large application and it has suffers from major
performance issues. I know that I know that the performance
is really bad. Where do I even begin to try
and figure out what is causing that?
Speaker 4 (11:49):
So the first suggestion is open your Chrome debtols, then
go to profile to performance stub, and in the performance
stub and start recording your interaction with the application. Once
you stop the recording, you will get the timeline with
a lot of information that you can use in order
(12:11):
to analyze the problems. Sometimes the Chrome is a Chrome
profiler is very smart and it will give you hints
like red squares or things like that, or will shout
at you that you have a lot of v flows,
which is something that I might mention later on. And
(12:33):
when you're analyzing those this timeline and all the things
inside of it, then you will be able to pinpoint
some parts of the applications that aren't performing very well,
and then you will be able to tune it those
problem problems at first, and later on, once you will
(12:56):
do this cycle again and again and again and again,
then you will be able to increase the performance. So
the idea is just open your Chrome their tools Profile,
Performance set tub and run some diagnostics later on. So
of those problems that you see and continue in doing
(13:19):
those cycles again and again and again and increase your performance.
This is something that might sound cumbersome. It is, but
the gain is very good. The gain is very fast.
You get a gain very fast. For example, did something
like that in a web application. It was three years ago.
(13:40):
They called me because they had a severe performance problem
in some web page that they had specific web page.
Got to know that. The company started recording profiling, found
the problem and it was stupid problem because most of
the problem that caused performance issues mainly that they're not smart.
(14:06):
The problem was the registered sum event handler that was
repeated and repeated and repeated very very fast. So the
page performance was degraded. And once we find found the problem,
(14:27):
and it was like twenty minutes after I arrived to
the customer, we solved it. It took one hour to
solve the problem, and I wasted the full consulting day
in one hour and thirty minutes, and they paid for
one hour and thirty minutes instead of eight hours that
(14:48):
they were supposed to pay. As they said, you solved
the problem very fast.
Speaker 7 (14:53):
So what you're saying is that the trick is to
identify the problem and then beat around the bush maybe
seven hours, and I go, ah, I've just found it
conveniently five minutes before I'm due to invoice you.
Speaker 4 (15:12):
No, I'm not doing that. It will hurt, It will
hurt my reputation. I was very happy that I solved
it so fast because they were complaining that the app
is such a huge thing and they can't go to
production with it. That was that was funny. But yes,
(15:34):
there are a lot of stories like that that you
you might find the performance problems very fast and solve
them very fast, and sometimes it is very elusive to
find the bugs that were created and creating the performance problems.
And with those times it might take a couple of
(15:56):
hours or even days to identify the problem. As we started,
we are CSI investigators. Sometimes your murder seen tells you everything.
Sometimes it's not.
Speaker 8 (16:11):
As far as Anguler goes. What's like the biggest obviously
not unsubscribing to observables, right, but what else is there
that causes large memory leaks or obvious ones that first of.
Speaker 4 (16:23):
All, you mentioned the obvious observables are the biggest thing
that can help you lick like like a ship that
is drowning. Because if you're not releasing those observables and
you're moving from one page to another, that is a problem.
(16:43):
That is the problem that will raise its ugly head
very soon. And I had a story of such a
problem two months ago in a company that they created
something very sophisticated and they didn't release an observdvable and
every time that they moved from one page to another,
(17:04):
that of observable included something like thirty five megabytes of
data and when you return to that page and move
again and return and move, you get spikes of memory lick.
And then they said something like, we have spikes of
(17:25):
thirty five megabytes. We don't understand where are they coming
from or why they are coming from. And this was
from ANGI rex store with index dB combination. And once
we unidentify those problems, we solved them. So observables are
mainly one problem. Another problem is change detection in Angular.
(17:52):
If you're not familiar with on push sometimes you can
cause various severe performance problems if you have a lot
of elements or for Star for eng four or things
like that, that you're replicating some elements in the dome.
(18:14):
If you're taking or doing things outside of anger angler
is not aware of the things you're doing outside if
you're using ANGI zone. So this might cause performance problems
of course animations when you're creating. When we are creating animations,
this if you know, we are not shipping frames to
(18:38):
the SCREM below ten milliseconds. This is the rule of
thumb for animation. You need ten milliseconds for each frame.
If it's not. If it's if you're doing something in
eleven milliseconds, then you might miss a frame and then
the performance of the elimation will be sluggish. Bit so
(19:02):
it's not the sixteen milliseconds that everybody's talking about, because
you have something like five to six milliseconds of overhead
that the browser and the operation system is doing underneath.
So ten milliseconds or sluggish animation. So these are the
(19:22):
main things that I can see in angular applications. Mostly
either it's observables or combinations of libraries that people are
using and not using in the standout way. Let's say
let's say that thing or things like animations that they're
(19:43):
creating and shipping frames be more than one sort milliseconds
and things like that.
Speaker 3 (19:50):
My question is quite related, but it comes like it's
in commission with this is like, you know, in security,
there is this o ass top ten of security risks.
What would be like the top three of performance risks?
Like if we have to have like a top three,
what let's sort them by by taking into account like
(20:13):
the frequency they appear and the impact Also like which
one like is the one you see that breaks apps?
Speaker 4 (20:21):
You know, large data sources. That's that's the main thing
that breaks ups large data sources. This is why there
are solutions out there, like out there like infinite scrolling
or virtualization, virtual scrolling or even filters for big data sets.
(20:42):
Once you are not aware that the amount of elements
that are created for each and every item in your
array might affect the performance of your web page, then
then you're creating a very non performance application or web page.
So the main thing is understanding that large datasets or
(21:07):
large data is something that you need to handle very carefully.
This is something that I had in an application that
I'm creating. These days, we have a very big data
set of patients coronavirus patients and helping the Israeli government
(21:28):
health department, and we have a lot of people who
got infected. So how do you create an app with
something like currently we have sixteen thousand people which were
affected by the coronavirus here in Israel, and so how
do you show all these data through your application? So
(21:51):
the solution that we used was adding over filtering data
and never show all the data all the time, because
if you're going to show all the data, your application
performance will break. Because for each patient, we have something
like seven to ten elements in the dome. So take
(22:16):
those ten elements for example, multiply them with sixteen thousand,
and there is a threshold that the browser will can't
handle so many elements simultaneously. So large data sources or
large data sets should be handled very carefully. They are
(22:38):
also the main thing that creates memory leaks. Later on,
if you're using large, large data sets or data sources,
then you're up will leak probably because of those data sources.
So this is the the number one problem of performance problem.
(23:00):
Should we continue to number two? Oh?
Speaker 6 (23:03):
What's number two?
Speaker 4 (23:06):
Number two is understanding the platform that you work in.
There are ways to create applications. Each and every platform
has its own constant pros. For example, if we're creating
Angular applications. We are creating application using Angular framework and
(23:29):
Angler is abstruction over them manipulation. So if we don't
understand how Angler work, and this is something that I
suggest every time, understand the tool that you're using, then
we might cause performance problems. Who remember the magic thing
in eng four in Angular one when you're creating Angular one,
(23:55):
there was a magic thing a filter that you're going
to put in Engine four to make it more performance.
Speaker 6 (24:03):
Filter in Angular JS for enery.
Speaker 4 (24:08):
An energie repeat.
Speaker 3 (24:09):
Yeah, oh yeah, No, it wasn't Angler adding a hash
to your item to track your items with the hash
if your data was in memory, but if you needed
a track by otherwise.
Speaker 4 (24:21):
So there was a thing in Angular a known performance
problem that you could solve in the in their change detection.
You just had to make indexes on the objects that
you're using. So I don't remember what it was we're
(24:44):
talking about four or five years ago, but every time
that I got to customer and they're working with the
Angular gs and they developers didn't know that you could
put the key on the engine repeat and then get
better performance by understanding how the platform is working. So
(25:08):
that's that's the second problem. Second problem with performance is us.
We are creating those the performance problems by not understanding
how things work. So this is me suggesting to open
the engine, who then just see how the engine is working.
Speaker 3 (25:30):
That's true, and though sometimes going to be relocated. But
then I have a question about that, like there are
so many things here to check out. But as you
said before, some issues can be solved in like half
an hour because it's just a listener to remove or
or non subscribe to a subscription channle or a track
(25:53):
by to add on ENG four or something like that.
But some performance issues but money lots of refacturing. So
which kind of issues are those and what are the
things that we should be careful about since the beginning
because otherwise can be very expensive to fix them.
Speaker 4 (26:13):
So we need to understand how the main problems that
can be caused by repaints and reflows. What is a reflow?
Reflow is a process in the browser that the browser
is triggering from time to time and it will be
triggered by manipulation of the dome. So for example, if
(26:36):
we are adding an element, we're moving an element, or
we're changing the layout of the web page, reflow can
be triggered the browsers try to optimize this process, and
this is something that we need to be aware of. Okay,
(26:56):
so if we're touching the dome, this is the main
thing that might cause a reflow, and the reflow is
expensive in terms of performance. Second thing that that I
said is repaint. In repaint, we change the color of
some element, we change the font size, things like that.
(27:22):
Those things can cause a repaint. Browser is repainting the
entire screen or in a section in the screen. This
is less expensive than reflow. But when when we understand
that changes in the dome or changes in that causes
painting are the main things that can impact the performance
(27:45):
of our page, then we try to minimize those impacts
by the combining or doing bulk changes, or doing bulk
cess changes, or things like that, things that were done
in jaquer in the past and are being done by
for example, in React by virtual Dome, that bulk change
(28:09):
is shipped to the dome or to the dome itself,
or in Angular in IVY, there are a lot of
changes that they did to make things, make bulk changes
or things like that to happen in order to avoid
those bigger not big, but a lot of reflows and
(28:33):
repaints that the browser might trigger. As developers, we aren't
or we can't affect when a reflow or repaint will happen.
But we should understand that these processes are happening and
the browser is doing those processes, and what triggers those
(28:53):
processes is the important thing. So once can understand that
we what triggers the the processes and avoid triggering those
processes a lot more repeatedly than we will be able
to affect the performance of our application or web page. Yeah,
(29:13):
any other questions from the funelists or you're in shock.
Speaker 3 (29:19):
We are repainting.
Speaker 4 (29:22):
This is something I did three weeks ago. When you
have a lot of spare time at at your home
because of social distancing, you repaint well.
Speaker 6 (29:33):
Thank you Gil for going over profiling with us and
basically what it is and how we can do it
better in our Angular applications. Do you guys have any
more questions before I move on to picks and how
we can find you online?
Speaker 3 (29:47):
I had a little question, Sorry for that, get into it.
So there are some features in Angular that help us
detect performance issues, but quite late, but you know, I'm
thinking about the budgets. You know, for example, that tells
you when your files are too big, or maybe because
(30:09):
you included like a huge styles or stuff like that.
And I think there's a lot of there are a
lot of things to add to these kind of features.
But what what kind of things you can think about
that we should add or some simple things we could
add to our projects, like I don't know, like detect
(30:30):
slow unit tests or things like that that can detect
some performance issues. What kind of alerts I can have,
Like I have a huge project, I don't want, I
don't have time to dive into it. What kind of
thing I can plug in it and get some indicators?
Doesn't mean there's a performance issue, but you know something
that can pop up here and there.
Speaker 4 (30:49):
There are monitoring tools that you can use on your applications.
You mentioned one of them which is Lighthouse, and you
can add it to the eye process. There are the
idea of window, those performance objects that you can use
in order to monitor by yourself. This is something that
(31:12):
you can plug your your code into it. You get
the performance object and you analyze the performance of the
web page by yourself or through puppeteer or things like that.
But there is no magic tool that you can row
(31:33):
into your application and find performance problems. Because problems are
created by developers, and because of that, it's very hard
to create a tool. No, it's not a very hard
thing to create it too, but there aren't a lot
of good tools to analyze performance problems or to add
(31:55):
to your angler application in code that in order to
money toward your performance. You can use Lighthouse as I said,
you can use Google Analytics to analyze things about about
your applications and all those monitor application that adds code
(32:17):
to your application, monitors your application, but because of that
degrade your performance a little bit. So either you do
it by yourself using the Window Doot Performance object, or
you can even use some outside tool. But there is
no something like a model that you can plug and
(32:42):
play with it to monitor your application, not that I'm
aware of.
Speaker 3 (32:49):
That's cool. So, but maybe like using the performance tool
to the Window performance to monitor some functions and for
maybe unit tests can be like a starting point. Like
I'm going to just function is doing a lot of
fork Let's see if it's not slowing down through the time.
Maybe that can be You will have to.
Speaker 4 (33:11):
Run to create a timer that you start running the
timer at the beginning and in the end. I did
that a few times in the past for some company
that created some analytics to understand the performance issues before death.
(33:33):
The Chrome dev tools did it for me. So you
can create those, but most most of the time you
will just need to add some profiling processes your development process.
As I said, just a suggestion.
Speaker 7 (33:54):
Cool.
Speaker 2 (33:55):
Thanks trying to Okay, Hello, hello, so we covered everything.
Anyone still has any questions? Okay, so good time to
go to the pigs, right.
Speaker 6 (34:11):
I have one that is related to what we've been
talking about. And actually the question that you just asked
was I was recently talking with Steven Fluin, who's the
Angular advocate on the Angular team, and he is like,
has this side project I don't know if you've heard
of it called bundlesize dot dev, and it is a
(34:33):
site that he's making currently working on. But you can
go there right now to analyze and benchmark your JavaScript
and type script. So you enter like the URL to
the site that you want to scan, and after like
scanning it, it pulls up like a bunch of numbers
about its bundle size, what version of Angler it's using,
and actually works for non Angular sites as well, So
(34:54):
it's really cool site, and he said, the more that
people use it, the more data he's going to have
to go off of. It basically gives you a score
on all other sites he's ever scanned, and so it's
like your performance or your your size is like around
ninety three percent out of you know, it's faster than
other sites are slower. So it's a really cool little side.
Speaker 3 (35:15):
Project he's got going. So check it out. It's bundlesize
dot dev.
Speaker 4 (35:19):
Nice.
Speaker 3 (35:19):
Thanks.
Speaker 2 (35:20):
Okay, let's go in the same order, Chris, What there
are picks?
Speaker 7 (35:25):
Yeah, I've got two picks today. First one is I've
been working from home now for seven weeks, I think,
and I don't particularly enjoy it. One of the issues
I had when I first started, when we all went
into lockdown is my internet speeds at home. I think
UK internet speeds are a little bit behind other parts
(35:45):
of the world anyway, but I was finding that the
room which has become my home office, I was getting
about one percent one to two percent of the download
speeds that I would get at my router. And also
only one thing could be on WiFi at a time,
so I had to have my phone. I'd have like
my phone just off of Wi Fi. If anyone could
hear my son is just outside the doors. Decided to
(36:07):
bear a little visit as well. Anyway, So I think
my Alexa must have heard me grumbling about this, because
one day on the Amazon homepage, suddenly this thing was
there called an Eero, and I'd never heard of it before,
and yet it was just there mystically on the front page.
And I mean, even as a technologist myself, I have
(36:28):
no idea how this thing works, but I thought I'll
give it a try. And it's just a home mesh
Wi Fi thing, and I bought a couple of them,
but I plugged in one of them. It's literally right
next to the router, and I suddenly had like a
I was getting like ten times the speeds in the
same room that I'm trying to work in. And then
I plugged in a second one, and now I get like,
(36:52):
basically about eighty percent of my of my router speeds
in my home office and everything can be connected at once,
and it's stenders.
Speaker 3 (37:01):
What is it.
Speaker 7 (37:01):
Basically the one that you plug You plug one into
your ridger and it just takes over, like all the
lights on my route are just gone. Off, the ERA
just completely took over it and instantly just boosted everything.
And then when you put additional ones around the house,
it just filters the Wi Fi around. I have no
idea how it works, but it has made my working
from home one hundred percent better. Like I actually I
can I can get on now, which is great. So
(37:23):
Era definitely my recommendation.
Speaker 2 (37:25):
Wow, sounds like what created the coronavirus, the slip conspiracy,
theories of five G and stuff like that.
Speaker 3 (37:32):
Yeah, do you think right here, do you think it
hacks like your neighbor's WiFi or something.
Speaker 4 (37:38):
I have no idea.
Speaker 7 (37:40):
Maybe maybe that's what it does. Maybe I have one
other pick. I like to pick entertaining Twitter accounts to
brighten up people's day. One that I particularly enjoy, especially
in these dark days, is called Grumpy Skeleton, and it's
this guy. He basically tweets as skeletor from but specific
(38:00):
the Skeleton from the nineteen eighties he Man and the
Masters of the Universe cartoon. I will I will give
a little bit of a disclaimer that he's kind of sweary,
So if you don't enjoy the swears in the tweets,
don't go and have a look. But if you're not
bothered by that, I go and have a look. Basically,
every time he tweets, he'll put a he must painstakingly
go through hours and hours of old he Man cartoons
(38:21):
because he puts a still from the cartoon and he'll
just write some amusing thing about how his henchmen are useless,
or how he Man's just an idiot trying to bash
down a door, how he's just trying to take over
Castle gray Scull but he can't because of social distancing
and stuff like that. The Grumpy Skeleton definitely recommend that
those are my picks today.
Speaker 2 (38:39):
Thanks, okay, Eddie, how about you?
Speaker 9 (38:43):
Nice? Well, so I am low on picks down, I
have one, so I'm gonna grab and steal Chris's Eero
one because hero is amazing. I've had mine for like
two years and it's it's awesome, So definitely recommend. I
have a four story townhouse and including like outdoor areas,
and I get perfect Internet like anywhere in the entire
four store townhouse or outside, so it's it's awesome. We
(39:07):
have three euroboxes that'll communicate, so that is great. And
then my real pick that wasn't stolen is animal crossing,
because you know, during a pandemic, what else do we
need them to go off to a deserted island and
have some fun. So I dove into that a little
bit over a week ago and my wife and I
(39:27):
got sucked into it, and I don't know what the
outside world is anymore. So I'm glad to see you all.
Speaker 4 (39:34):
Nice.
Speaker 3 (39:35):
Thanks you, and this hey from the button for the mic.
So yeah, I have one pick and it's Angler related surprise.
So it's a library by that Michael Lake have been
working on a lot. So Michael Lake works a lot
on Angler and rchas content and things like that, and
(39:56):
he built this library called rix Angler, which is based
on another library built called erxjs state, which tries to
fix an issue which is, you know, either you end
up putting everything in your NGRX or your application global states,
or either you handle your stuff in your components and
(40:21):
you end up with lots of subscriptions and then having
to use other libraries to handle those subscriptions. And the
idea of our angular state is there are lots of
ideas in it, but one of the ideas is like
to have a local component state without having to subscribe
manually to it, so you got lots of all observables
and you connect it to your inputs, You connect it
(40:42):
to lots of things in your components and to the
life cycles, and you don't have to care about these things.
And it helps you write reactive stuff without having to
put all your logic JRX, which is not something you
want to do all the time. That's it, very serious things. Funny,
(41:03):
Sorry for that.
Speaker 2 (41:06):
Nice, Thank you, Thank you for the unfunny pick.
Speaker 3 (41:09):
Uns. That's my job.
Speaker 10 (41:11):
That's yeah, now, but that's actually great that Michael is
doing great work around trying to simplify state management.
Speaker 4 (41:22):
So that's a great pick. Okay, so Brooks.
Speaker 8 (41:26):
Yeah, so my pick is loop back for It's a
no JS typescript framework for building you know API. I
got into a recently client had a project with it,
and I had never heard of it before. It's actually
made by IBM. It's open source and it has a
really powerful CLI, which is like the coolest part of it.
(41:49):
You kind of answer questions and all of a sudden
your endpoints are made and working. So it's very cool.
Speaker 4 (41:56):
Nice.
Speaker 2 (41:56):
It's an alternative to the popular nest right, yeah, exactly, Yeah,
awesome great pick. Okay, so my pick is a shameless plug. First,
testangular dot com. We're going to launch another workshop testing workshop,
free testing workshop, So if you go to testangular dot
(42:19):
com and sign.
Speaker 4 (42:20):
Up, should be up this month.
Speaker 2 (42:22):
It was supposed to be an April but Corona and
my other pick is Angie Coon.
Speaker 5 (42:29):
So ngiconf released their videos which I had the pleasure
to be a part of. So you could go to
angconf dot com dot org and register for free and
you can see the lectures. So that's my second pick.
And now for the guest of honor, Yille, what are
your picks?
Speaker 4 (42:50):
I have two picks. One is related to a friend,
the mutual friend of us, wish A Kain. We started
the new venture. He calls it walk We. That application
helps to create our the Winno. It's our our window
playground in the web and it's looking for people who
(43:13):
will help create more components, our the window components, but
in the web environment like you will have to create
those elements using gleat dash element if you know that library.
So one it's Risha Kid's walk We and the second
one is not related to anything but to today. We're
(43:37):
recording and today is the fourth of May and it's
Star Wars Day, and today I'm very fun of Star
Wars things, and one of the things that I'm looking
forward is to see the last episode of the Star Wars.
(43:57):
The Clone World War was animated series that will be
shipped today, So today there is the last episode of
that series, so I'm looking forward for tonight to see
it later on awesome.
Speaker 2 (44:13):
Thank you very much Gil for sharing with us all
the wonderful tricks and tapes a while profiling. Thank you
all all the panelists for joining today, and we'll see
you next time on another great episode of Adventures in Angela.
Speaker 4 (44:30):
Bye bye, thank you everybody. Beys everyone,
Hello everybody, and welcome to another episode of Adventures in Angular.
I'm Shy Wrestling from testangular dot com and today we
have our panelist from the Order in the Zoom Chris Ford.
Speaker 2 (00:21):
Hello, Hello, Eddie Hingele everyone, Uns, j D Hello, Alisa
and Chell Hello Hello.
Speaker 3 (00:30):
And Brooks Force sure hey everyone, and today we.
Speaker 1 (00:36):
Are hosting a very good friend of ours and also
Angular canon, which means a very good developer.
Speaker 4 (00:45):
Gil think he everybody nice to be here.
Speaker 5 (00:49):
Nice?
Speaker 2 (00:50):
So Gil first of all introduced yourself, not to us
because we already know you, but to all the listeners
who might not know you.
Speaker 4 (01:00):
Who are you?
Speaker 2 (01:01):
What have you been doing this afternoon? And what's up
in general?
Speaker 4 (01:06):
So I'm Guil think I'm the CEO of Sparksis. It's
my own company. It only have one employee me myself.
Speaker 2 (01:15):
And Night, so you're also the janitor.
Speaker 4 (01:18):
I'm also cleaning the house because as a freelancer, my
house is my office. So of ten years of Microsoft
Most Vulnerable Professional GDE, you will developer expert in web
technologies wrote a book that you can find in the
(01:40):
Amazon called Crow Single Page Application Development One kevit with
the book it was written into twenty fourteen and it's
in backbone.
Speaker 6 (01:51):
So anyway, you've only written one book. I thought you
had like a like a library of books.
Speaker 4 (01:58):
I wrote a book, but I also wrote a few
Microsoft Official courses that were learned in Microsoft Official you know,
some learning centers all over the world, so things like
HTML five, programming, working with the apps in Windows eight,
and et cetera, et cetera. Should I say, writing Windows
(02:22):
apps And that's all. I'm also helping in organizing conferences
like Angler up and React next in Israel, so you're
very welcome to come to Israel someday when this Corona
crisis will end.
Speaker 6 (02:40):
Nice.
Speaker 2 (02:41):
And also you organize the Javaskirt Israel meetup group.
Speaker 4 (02:46):
I'm one of the organizers. I can say that I'm
organizing all the meetups. But you're managing the content team,
and I'm in part of the content team. So yeah,
this is.
Speaker 2 (02:58):
How I knew that. Okay, So thanks, And so today's
topic is about profiling, right, so it will be amazing
if we'll talk about first the problems that we need
profiling for to solve, and then you could take us
(03:19):
through a.
Speaker 6 (03:19):
Journey maybe, like let's first talk about like what is
profiling like what is what does it given me?
Speaker 4 (03:26):
So think about yourself as a CSI guy or a girl,
and the idea of profiling is to find problems problems
that you might have. But if we're talking more exactly
about development, then most of the time when we're talking
(03:46):
about profiling, we're talking about profiling or finding bottlenecks, memory leaks,
and things like that. So we are trying to understand
problems that we have in our software, and by finding
those problems we and solving them, we may improve the
(04:08):
performance of our application, either with the memory consumption of
the application or how fast we ship frames to the screen.
Speaker 2 (04:20):
Also, so that's an amazing analogy. Okay, we're a CSI
team here. Okay, people, now, now we have a problem
where we are in the crimes and what do we see?
What are the problems that we need to profile.
Speaker 4 (04:36):
So most of the time, when we are not seeing
the problems, we will find the problems by our users.
What I mean by that, most of the time when
I'm coming to companies, I'm coming and helping as a
consultant because the users are renting about bad performance, either
(04:58):
because they used app in a device with slow CPU
or they use your your app in a web browser,
that is in some you know, mobile phone or tablet
or whatever, and they're complaining that things aren't working, things
(05:20):
are creaking. You have junk with a not with you,
meaning that when frames are shipped to the screen. We
have a screen rate of sixty frames per second, and
if you go below that frame rate, then you will
have quirks in your animation, in your UI, in everything.
(05:44):
So the idea is to make your patients fast and
fluid and that the users won't complain. What I'm suggesting
mostly for companies is to add development in the development cycles.
Also performance or should I say profiling or performance cycles
(06:05):
means that add those cycles to the development phase and
not to the you know, maintenance when when the users
are complaining, find the problems before they are created?
Speaker 2 (06:19):
Wait, how do you do that?
Speaker 4 (06:20):
How do you do what?
Speaker 6 (06:22):
How do you how do you find the problems before
they're created?
Speaker 4 (06:25):
As I said, add pro filing cycles to your development phase.
What I mean by that is but okay, So the
idea is as following you can take There is a
profiling process that is very very profound. What what you're
(06:45):
doing that process is the following You establish some baseline.
That means that you're creating a branch to your application
or something like that, and you're working in incognitum mode
for example, not affect the performance of the application by
outer means like extensions in the browser or things like that.
(07:09):
After you establish that baseline, you start the profiling process,
which is the process is collect the data. You're collecting
the data using probably your developer tools from developer tools
Firebag in Mozilla or whatever you like. You collect the
data using those tools, and then you analyze the results.
(07:33):
If you're analyzing the results and you find some problems,
and you will find problems probably, then you tune up
the application. What I mean by that you try to
solve the problems, the bottlenecks that you find by adjusting
your algorithms or thinking about how to improve the loops
(07:54):
that you've created or things like that. Once you finish
tuning up the application, test and measure. You test if
the tune up worked or not, and then you continue
on collecting data, analyzing, tuning and testing and measuring. Then
this is the profiling process. That process helps you to
understand how if there are bottlenecks or performance problems, and
(08:20):
then find them and probably or should I say, hopefully,
solve them before they are shipped into the world of
your users.
Speaker 3 (08:32):
And maybe you're going to talk about this later, but
how would you integrate this in your continuous delivery or
continuous integration? Which parts could be automated? Which parts? Which
part would you recommend to automate or to not automate
or just let's not care about automation.
Speaker 4 (08:51):
I'm carrying about automation, and that's a good question. Unfortunately,
most of the tools that we are using to file
applications are the developer tools. You can do that through puppeteer,
but I don't think that there is a solution that
automates this process, okay, or most of the time when
(09:15):
you're doing that process, it's manually. And that's an idea
for finding or tracking things. Maybe someone who listening to
us will take that globe that you throw it my
face and start thinking about how to add profiling processes
in CI. That's an interesting idea. Have you learned or
(09:41):
do you know a tool that is doing that?
Speaker 3 (09:43):
No, really, I know that there's a way of adding
lighthouse to your CI. Never never dived into that, but
I think it's going to be limited. It's going to
be just some monitoring, not real profiling and aware of anything.
Speaker 4 (09:58):
Lighthouse is cool and I'm using it a lot to
start finding problems, but the real problems you won't find
with Lighthouse. You will find how many HTDP requests your
app or your web pages are doing, and some suggestions
of how to to make image optimizations or other stuff,
(10:23):
But the hardcore bottlenecks you won't be able to find
with Lighthouse. So this is not an ideal tool for that.
But I know that you can add Lighthouse to your
your CI and monitor static, monitor your web pages, or
(10:44):
your way back.
Speaker 6 (10:46):
So it's like Lighthouse is a way to get started,
but it's not a way to like find the deeper issues,
is what you're saying.
Speaker 4 (10:54):
It's when we're talking about deeper issues, we need to
understand how things are working in the browser, and for
that when we need to understand how pixel pipeline is working,
and how where the browser is shipping the frames to
the device screen, and what should we do in order
(11:18):
to increase performance or what should we avoid in order
to increase our web page performance.
Speaker 7 (11:27):
As a scenario for you, and it may or may
not be based on a true story. Say I'm working
on a large application and it has suffers from major
performance issues. I know that I know that the performance
is really bad. Where do I even begin to try
and figure out what is causing that?
Speaker 4 (11:49):
So the first suggestion is open your Chrome debtols, then
go to profile to performance stub, and in the performance
stub and start recording your interaction with the application. Once
you stop the recording, you will get the timeline with
a lot of information that you can use in order
(12:11):
to analyze the problems. Sometimes the Chrome is a Chrome
profiler is very smart and it will give you hints
like red squares or things like that, or will shout
at you that you have a lot of v flows,
which is something that I might mention later on. And
(12:33):
when you're analyzing those this timeline and all the things
inside of it, then you will be able to pinpoint
some parts of the applications that aren't performing very well,
and then you will be able to tune it those
problem problems at first, and later on, once you will
(12:56):
do this cycle again and again and again and again,
then you will be able to increase the performance. So
the idea is just open your Chrome their tools Profile,
Performance set tub and run some diagnostics later on. So
of those problems that you see and continue in doing
(13:19):
those cycles again and again and again and increase your performance.
This is something that might sound cumbersome. It is, but
the gain is very good. The gain is very fast.
You get a gain very fast. For example, did something
like that in a web application. It was three years ago.
(13:40):
They called me because they had a severe performance problem
in some web page that they had specific web page.
Got to know that. The company started recording profiling, found
the problem and it was stupid problem because most of
the problem that caused performance issues mainly that they're not smart.
(14:06):
The problem was the registered sum event handler that was
repeated and repeated and repeated very very fast. So the
page performance was degraded. And once we find found the problem,
(14:27):
and it was like twenty minutes after I arrived to
the customer, we solved it. It took one hour to
solve the problem, and I wasted the full consulting day
in one hour and thirty minutes, and they paid for
one hour and thirty minutes instead of eight hours that
(14:48):
they were supposed to pay. As they said, you solved
the problem very fast.
Speaker 7 (14:53):
So what you're saying is that the trick is to
identify the problem and then beat around the bush maybe
seven hours, and I go, ah, I've just found it
conveniently five minutes before I'm due to invoice you.
Speaker 4 (15:12):
No, I'm not doing that. It will hurt, It will
hurt my reputation. I was very happy that I solved
it so fast because they were complaining that the app
is such a huge thing and they can't go to
production with it. That was that was funny. But yes,
(15:34):
there are a lot of stories like that that you
you might find the performance problems very fast and solve
them very fast, and sometimes it is very elusive to
find the bugs that were created and creating the performance problems.
And with those times it might take a couple of
(15:56):
hours or even days to identify the problem. As we started,
we are CSI investigators. Sometimes your murder seen tells you everything.
Sometimes it's not.
Speaker 8 (16:11):
As far as Anguler goes. What's like the biggest obviously
not unsubscribing to observables, right, but what else is there
that causes large memory leaks or obvious ones that first of.
Speaker 4 (16:23):
All, you mentioned the obvious observables are the biggest thing
that can help you lick like like a ship that
is drowning. Because if you're not releasing those observables and
you're moving from one page to another, that is a problem.
(16:43):
That is the problem that will raise its ugly head
very soon. And I had a story of such a
problem two months ago in a company that they created
something very sophisticated and they didn't release an observdvable and
every time that they moved from one page to another,
(17:04):
that of observable included something like thirty five megabytes of
data and when you return to that page and move
again and return and move, you get spikes of memory lick.
And then they said something like, we have spikes of
(17:25):
thirty five megabytes. We don't understand where are they coming
from or why they are coming from. And this was
from ANGI rex store with index dB combination. And once
we unidentify those problems, we solved them. So observables are
mainly one problem. Another problem is change detection in Angular.
(17:52):
If you're not familiar with on push sometimes you can
cause various severe performance problems if you have a lot
of elements or for Star for eng four or things
like that, that you're replicating some elements in the dome.
(18:14):
If you're taking or doing things outside of anger angler
is not aware of the things you're doing outside if
you're using ANGI zone. So this might cause performance problems
of course animations when you're creating. When we are creating animations,
this if you know, we are not shipping frames to
(18:38):
the SCREM below ten milliseconds. This is the rule of
thumb for animation. You need ten milliseconds for each frame.
If it's not. If it's if you're doing something in
eleven milliseconds, then you might miss a frame and then
the performance of the elimation will be sluggish. Bit so
(19:02):
it's not the sixteen milliseconds that everybody's talking about, because
you have something like five to six milliseconds of overhead
that the browser and the operation system is doing underneath.
So ten milliseconds or sluggish animation. So these are the
(19:22):
main things that I can see in angular applications. Mostly
either it's observables or combinations of libraries that people are
using and not using in the standout way. Let's say
let's say that thing or things like animations that they're
(19:43):
creating and shipping frames be more than one sort milliseconds
and things like that.
Speaker 3 (19:50):
My question is quite related, but it comes like it's
in commission with this is like, you know, in security,
there is this o ass top ten of security risks.
What would be like the top three of performance risks?
Like if we have to have like a top three,
what let's sort them by by taking into account like
(20:13):
the frequency they appear and the impact Also like which
one like is the one you see that breaks apps?
Speaker 4 (20:21):
You know, large data sources. That's that's the main thing
that breaks ups large data sources. This is why there
are solutions out there, like out there like infinite scrolling
or virtualization, virtual scrolling or even filters for big data sets.
(20:42):
Once you are not aware that the amount of elements
that are created for each and every item in your
array might affect the performance of your web page, then
then you're creating a very non performance application or web page.
So the main thing is understanding that large datasets or
(21:07):
large data is something that you need to handle very carefully.
This is something that I had in an application that
I'm creating. These days, we have a very big data
set of patients coronavirus patients and helping the Israeli government
(21:28):
health department, and we have a lot of people who
got infected. So how do you create an app with
something like currently we have sixteen thousand people which were
affected by the coronavirus here in Israel, and so how
do you show all these data through your application? So
(21:51):
the solution that we used was adding over filtering data
and never show all the data all the time, because
if you're going to show all the data, your application
performance will break. Because for each patient, we have something
like seven to ten elements in the dome. So take
(22:16):
those ten elements for example, multiply them with sixteen thousand,
and there is a threshold that the browser will can't
handle so many elements simultaneously. So large data sources or
large data sets should be handled very carefully. They are
(22:38):
also the main thing that creates memory leaks. Later on,
if you're using large, large data sets or data sources,
then you're up will leak probably because of those data sources.
So this is the the number one problem of performance problem.
(23:00):
Should we continue to number two? Oh?
Speaker 6 (23:03):
What's number two?
Speaker 4 (23:06):
Number two is understanding the platform that you work in.
There are ways to create applications. Each and every platform
has its own constant pros. For example, if we're creating
Angular applications. We are creating application using Angular framework and
(23:29):
Angler is abstruction over them manipulation. So if we don't
understand how Angler work, and this is something that I
suggest every time, understand the tool that you're using, then
we might cause performance problems. Who remember the magic thing
in eng four in Angular one when you're creating Angular one,
(23:55):
there was a magic thing a filter that you're going
to put in Engine four to make it more performance.
Speaker 6 (24:03):
Filter in Angular JS for enery.
Speaker 4 (24:08):
An energie repeat.
Speaker 3 (24:09):
Yeah, oh yeah, No, it wasn't Angler adding a hash
to your item to track your items with the hash
if your data was in memory, but if you needed
a track by otherwise.
Speaker 4 (24:21):
So there was a thing in Angular a known performance
problem that you could solve in the in their change detection.
You just had to make indexes on the objects that
you're using. So I don't remember what it was we're
(24:44):
talking about four or five years ago, but every time
that I got to customer and they're working with the
Angular gs and they developers didn't know that you could
put the key on the engine repeat and then get
better performance by understanding how the platform is working. So
(25:08):
that's that's the second problem. Second problem with performance is us.
We are creating those the performance problems by not understanding
how things work. So this is me suggesting to open
the engine, who then just see how the engine is working.
Speaker 3 (25:30):
That's true, and though sometimes going to be relocated. But
then I have a question about that, like there are
so many things here to check out. But as you
said before, some issues can be solved in like half
an hour because it's just a listener to remove or
or non subscribe to a subscription channle or a track
(25:53):
by to add on ENG four or something like that.
But some performance issues but money lots of refacturing. So
which kind of issues are those and what are the
things that we should be careful about since the beginning
because otherwise can be very expensive to fix them.
Speaker 4 (26:13):
So we need to understand how the main problems that
can be caused by repaints and reflows. What is a reflow?
Reflow is a process in the browser that the browser
is triggering from time to time and it will be
triggered by manipulation of the dome. So for example, if
(26:36):
we are adding an element, we're moving an element, or
we're changing the layout of the web page, reflow can
be triggered the browsers try to optimize this process, and
this is something that we need to be aware of. Okay,
(26:56):
so if we're touching the dome, this is the main
thing that might cause a reflow, and the reflow is
expensive in terms of performance. Second thing that that I
said is repaint. In repaint, we change the color of
some element, we change the font size, things like that.
(27:22):
Those things can cause a repaint. Browser is repainting the
entire screen or in a section in the screen. This
is less expensive than reflow. But when when we understand
that changes in the dome or changes in that causes
painting are the main things that can impact the performance
(27:45):
of our page, then we try to minimize those impacts
by the combining or doing bulk changes, or doing bulk
cess changes, or things like that, things that were done
in jaquer in the past and are being done by
for example, in React by virtual Dome, that bulk change
(28:09):
is shipped to the dome or to the dome itself,
or in Angular in IVY, there are a lot of
changes that they did to make things, make bulk changes
or things like that to happen in order to avoid
those bigger not big, but a lot of reflows and
(28:33):
repaints that the browser might trigger. As developers, we aren't
or we can't affect when a reflow or repaint will happen.
But we should understand that these processes are happening and
the browser is doing those processes, and what triggers those
(28:53):
processes is the important thing. So once can understand that
we what triggers the the processes and avoid triggering those
processes a lot more repeatedly than we will be able
to affect the performance of our application or web page. Yeah,
(29:13):
any other questions from the funelists or you're in shock.
Speaker 3 (29:19):
We are repainting.
Speaker 4 (29:22):
This is something I did three weeks ago. When you
have a lot of spare time at at your home
because of social distancing, you repaint well.
Speaker 6 (29:33):
Thank you Gil for going over profiling with us and
basically what it is and how we can do it
better in our Angular applications. Do you guys have any
more questions before I move on to picks and how
we can find you online?
Speaker 3 (29:47):
I had a little question, Sorry for that, get into it.
So there are some features in Angular that help us
detect performance issues, but quite late, but you know, I'm
thinking about the budgets. You know, for example, that tells
you when your files are too big, or maybe because
(30:09):
you included like a huge styles or stuff like that.
And I think there's a lot of there are a
lot of things to add to these kind of features.
But what what kind of things you can think about
that we should add or some simple things we could
add to our projects, like I don't know, like detect
(30:30):
slow unit tests or things like that that can detect
some performance issues. What kind of alerts I can have,
Like I have a huge project, I don't want, I
don't have time to dive into it. What kind of
thing I can plug in it and get some indicators?
Doesn't mean there's a performance issue, but you know something
that can pop up here and there.
Speaker 4 (30:49):
There are monitoring tools that you can use on your applications.
You mentioned one of them which is Lighthouse, and you
can add it to the eye process. There are the
idea of window, those performance objects that you can use
in order to monitor by yourself. This is something that
(31:12):
you can plug your your code into it. You get
the performance object and you analyze the performance of the
web page by yourself or through puppeteer or things like that.
But there is no magic tool that you can row
(31:33):
into your application and find performance problems. Because problems are
created by developers, and because of that, it's very hard
to create a tool. No, it's not a very hard
thing to create it too, but there aren't a lot
of good tools to analyze performance problems or to add
(31:55):
to your angler application in code that in order to
money toward your performance. You can use Lighthouse as I said,
you can use Google Analytics to analyze things about about
your applications and all those monitor application that adds code
(32:17):
to your application, monitors your application, but because of that
degrade your performance a little bit. So either you do
it by yourself using the Window Doot Performance object, or
you can even use some outside tool. But there is
no something like a model that you can plug and
(32:42):
play with it to monitor your application, not that I'm
aware of.
Speaker 3 (32:49):
That's cool. So, but maybe like using the performance tool
to the Window performance to monitor some functions and for
maybe unit tests can be like a starting point. Like
I'm going to just function is doing a lot of
fork Let's see if it's not slowing down through the time.
Maybe that can be You will have to.
Speaker 4 (33:11):
Run to create a timer that you start running the
timer at the beginning and in the end. I did
that a few times in the past for some company
that created some analytics to understand the performance issues before death.
(33:33):
The Chrome dev tools did it for me. So you
can create those, but most most of the time you
will just need to add some profiling processes your development process.
As I said, just a suggestion.
Speaker 7 (33:54):
Cool.
Speaker 2 (33:55):
Thanks trying to Okay, Hello, hello, so we covered everything.
Anyone still has any questions? Okay, so good time to
go to the pigs, right.
Speaker 6 (34:11):
I have one that is related to what we've been
talking about. And actually the question that you just asked
was I was recently talking with Steven Fluin, who's the
Angular advocate on the Angular team, and he is like,
has this side project I don't know if you've heard
of it called bundlesize dot dev, and it is a
(34:33):
site that he's making currently working on. But you can
go there right now to analyze and benchmark your JavaScript
and type script. So you enter like the URL to
the site that you want to scan, and after like
scanning it, it pulls up like a bunch of numbers
about its bundle size, what version of Angler it's using,
and actually works for non Angular sites as well, So
(34:54):
it's really cool site, and he said, the more that
people use it, the more data he's going to have
to go off of. It basically gives you a score
on all other sites he's ever scanned, and so it's
like your performance or your your size is like around
ninety three percent out of you know, it's faster than
other sites are slower. So it's a really cool little side.
Speaker 3 (35:15):
Project he's got going. So check it out. It's bundlesize
dot dev.
Speaker 4 (35:19):
Nice.
Speaker 3 (35:19):
Thanks.
Speaker 2 (35:20):
Okay, let's go in the same order, Chris, What there
are picks?
Speaker 7 (35:25):
Yeah, I've got two picks today. First one is I've
been working from home now for seven weeks, I think,
and I don't particularly enjoy it. One of the issues
I had when I first started, when we all went
into lockdown is my internet speeds at home. I think
UK internet speeds are a little bit behind other parts
(35:45):
of the world anyway, but I was finding that the
room which has become my home office, I was getting
about one percent one to two percent of the download
speeds that I would get at my router. And also
only one thing could be on WiFi at a time,
so I had to have my phone. I'd have like
my phone just off of Wi Fi. If anyone could
hear my son is just outside the doors. Decided to
(36:07):
bear a little visit as well. Anyway, So I think
my Alexa must have heard me grumbling about this, because
one day on the Amazon homepage, suddenly this thing was
there called an Eero, and I'd never heard of it before,
and yet it was just there mystically on the front page.
And I mean, even as a technologist myself, I have
(36:28):
no idea how this thing works, but I thought I'll
give it a try. And it's just a home mesh
Wi Fi thing, and I bought a couple of them,
but I plugged in one of them. It's literally right
next to the router, and I suddenly had like a
I was getting like ten times the speeds in the
same room that I'm trying to work in. And then
I plugged in a second one, and now I get like,
(36:52):
basically about eighty percent of my of my router speeds
in my home office and everything can be connected at once,
and it's stenders.
Speaker 3 (37:01):
What is it.
Speaker 7 (37:01):
Basically the one that you plug You plug one into
your ridger and it just takes over, like all the
lights on my route are just gone. Off, the ERA
just completely took over it and instantly just boosted everything.
And then when you put additional ones around the house,
it just filters the Wi Fi around. I have no
idea how it works, but it has made my working
from home one hundred percent better. Like I actually I
can I can get on now, which is great. So
(37:23):
Era definitely my recommendation.
Speaker 2 (37:25):
Wow, sounds like what created the coronavirus, the slip conspiracy,
theories of five G and stuff like that.
Speaker 3 (37:32):
Yeah, do you think right here, do you think it
hacks like your neighbor's WiFi or something.
Speaker 4 (37:38):
I have no idea.
Speaker 7 (37:40):
Maybe maybe that's what it does. Maybe I have one
other pick. I like to pick entertaining Twitter accounts to
brighten up people's day. One that I particularly enjoy, especially
in these dark days, is called Grumpy Skeleton, and it's
this guy. He basically tweets as skeletor from but specific
(38:00):
the Skeleton from the nineteen eighties he Man and the
Masters of the Universe cartoon. I will I will give
a little bit of a disclaimer that he's kind of sweary,
So if you don't enjoy the swears in the tweets,
don't go and have a look. But if you're not
bothered by that, I go and have a look. Basically,
every time he tweets, he'll put a he must painstakingly
go through hours and hours of old he Man cartoons
(38:21):
because he puts a still from the cartoon and he'll
just write some amusing thing about how his henchmen are useless,
or how he Man's just an idiot trying to bash
down a door, how he's just trying to take over
Castle gray Scull but he can't because of social distancing
and stuff like that. The Grumpy Skeleton definitely recommend that
those are my picks today.
Speaker 2 (38:39):
Thanks, okay, Eddie, how about you?
Speaker 9 (38:43):
Nice? Well, so I am low on picks down, I
have one, so I'm gonna grab and steal Chris's Eero
one because hero is amazing. I've had mine for like
two years and it's it's awesome, So definitely recommend. I
have a four story townhouse and including like outdoor areas,
and I get perfect Internet like anywhere in the entire
four store townhouse or outside, so it's it's awesome. We
(39:07):
have three euroboxes that'll communicate, so that is great. And
then my real pick that wasn't stolen is animal crossing,
because you know, during a pandemic, what else do we
need them to go off to a deserted island and
have some fun. So I dove into that a little
bit over a week ago and my wife and I
(39:27):
got sucked into it, and I don't know what the
outside world is anymore. So I'm glad to see you all.
Speaker 4 (39:34):
Nice.
Speaker 3 (39:35):
Thanks you, and this hey from the button for the mic.
So yeah, I have one pick and it's Angler related surprise.
So it's a library by that Michael Lake have been
working on a lot. So Michael Lake works a lot
on Angler and rchas content and things like that, and
(39:56):
he built this library called rix Angler, which is based
on another library built called erxjs state, which tries to
fix an issue which is, you know, either you end
up putting everything in your NGRX or your application global states,
or either you handle your stuff in your components and
(40:21):
you end up with lots of subscriptions and then having
to use other libraries to handle those subscriptions. And the
idea of our angular state is there are lots of
ideas in it, but one of the ideas is like
to have a local component state without having to subscribe
manually to it, so you got lots of all observables
and you connect it to your inputs, You connect it
(40:42):
to lots of things in your components and to the
life cycles, and you don't have to care about these things.
And it helps you write reactive stuff without having to
put all your logic JRX, which is not something you
want to do all the time. That's it, very serious things. Funny,
(41:03):
Sorry for that.
Speaker 2 (41:06):
Nice, Thank you, Thank you for the unfunny pick.
Speaker 3 (41:09):
Uns. That's my job.
Speaker 10 (41:11):
That's yeah, now, but that's actually great that Michael is
doing great work around trying to simplify state management.
Speaker 4 (41:22):
So that's a great pick. Okay, so Brooks.
Speaker 8 (41:26):
Yeah, so my pick is loop back for It's a
no JS typescript framework for building you know API. I
got into a recently client had a project with it,
and I had never heard of it before. It's actually
made by IBM. It's open source and it has a
really powerful CLI, which is like the coolest part of it.
(41:49):
You kind of answer questions and all of a sudden
your endpoints are made and working. So it's very cool.
Speaker 4 (41:56):
Nice.
Speaker 2 (41:56):
It's an alternative to the popular nest right, yeah, exactly, Yeah,
awesome great pick. Okay, so my pick is a shameless plug. First,
testangular dot com. We're going to launch another workshop testing workshop,
free testing workshop, So if you go to testangular dot
(42:19):
com and sign.
Speaker 4 (42:20):
Up, should be up this month.
Speaker 2 (42:22):
It was supposed to be an April but Corona and
my other pick is Angie Coon.
Speaker 5 (42:29):
So ngiconf released their videos which I had the pleasure
to be a part of. So you could go to
angconf dot com dot org and register for free and
you can see the lectures. So that's my second pick.
And now for the guest of honor, Yille, what are
your picks?
Speaker 4 (42:50):
I have two picks. One is related to a friend,
the mutual friend of us, wish A Kain. We started
the new venture. He calls it walk We. That application
helps to create our the Winno. It's our our window
playground in the web and it's looking for people who
(43:13):
will help create more components, our the window components, but
in the web environment like you will have to create
those elements using gleat dash element if you know that library.
So one it's Risha Kid's walk We and the second
one is not related to anything but to today. We're
(43:37):
recording and today is the fourth of May and it's
Star Wars Day, and today I'm very fun of Star
Wars things, and one of the things that I'm looking
forward is to see the last episode of the Star Wars.
(43:57):
The Clone World War was animated series that will be
shipped today, So today there is the last episode of
that series, so I'm looking forward for tonight to see
it later on awesome.
Speaker 2 (44:13):
Thank you very much Gil for sharing with us all
the wonderful tricks and tapes a while profiling. Thank you
all all the panelists for joining today, and we'll see
you next time on another great episode of Adventures in Angela.
Speaker 4 (44:30):
Bye bye, thank you everybody. Beys everyone,
Popular Podcasts
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.