1
00:00:06,719 --> 00:00:10,720
Speaker 1: Hello everybody, and welcome to another episode of Adventures in Angular.

2
00:00:11,519 --> 00:00:15,679
I'm Shy Wrestling from testangular dot com and today we

3
00:00:15,800 --> 00:00:20,679
have our panelist from the Order in the Zoom Chris Ford.

4
00:00:21,079 --> 00:00:28,359
Speaker 2: Hello, Hello, Eddie Hingele everyone, Uns, j D Hello, Alisa

5
00:00:28,399 --> 00:00:30,559
and Chell Hello Hello.

6
00:00:30,719 --> 00:00:36,240
Speaker 3: And Brooks Force sure hey everyone, and today we.

7
00:00:36,200 --> 00:00:40,399
Speaker 1: Are hosting a very good friend of ours and also

8
00:00:40,719 --> 00:00:44,719
Angular canon, which means a very good developer.

9
00:00:45,039 --> 00:00:48,960
Speaker 4: Gil think he everybody nice to be here.

10
00:00:49,399 --> 00:00:49,759
Speaker 5: Nice?

11
00:00:50,320 --> 00:00:54,920
Speaker 2: So Gil first of all introduced yourself, not to us

12
00:00:55,200 --> 00:00:58,359
because we already know you, but to all the listeners

13
00:00:58,759 --> 00:01:00,200
who might not know you.

14
00:01:00,719 --> 00:01:01,280
Speaker 4: Who are you?

15
00:01:01,960 --> 00:01:05,519
Speaker 2: What have you been doing this afternoon? And what's up

16
00:01:05,519 --> 00:01:06,040
in general?

17
00:01:06,599 --> 00:01:11,200
Speaker 4: So I'm Guil think I'm the CEO of Sparksis. It's

18
00:01:11,239 --> 00:01:16,120
my own company. It only have one employee me myself.

19
00:01:15,799 --> 00:01:17,760
Speaker 2: And Night, so you're also the janitor.

20
00:01:18,519 --> 00:01:24,040
Speaker 4: I'm also cleaning the house because as a freelancer, my

21
00:01:24,159 --> 00:01:32,120
house is my office. So of ten years of Microsoft

22
00:01:32,400 --> 00:01:36,519
Most Vulnerable Professional GDE, you will developer expert in web

23
00:01:36,560 --> 00:01:40,799
technologies wrote a book that you can find in the

24
00:01:40,920 --> 00:01:45,239
Amazon called Crow Single Page Application Development One kevit with

25
00:01:45,840 --> 00:01:50,120
the book it was written into twenty fourteen and it's

26
00:01:50,159 --> 00:01:51,239
in backbone.

27
00:01:51,879 --> 00:01:55,239
Speaker 6: So anyway, you've only written one book. I thought you

28
00:01:55,280 --> 00:01:58,239
had like a like a library of books.

29
00:01:58,319 --> 00:02:02,359
Speaker 4: I wrote a book, but I also wrote a few

30
00:02:02,439 --> 00:02:08,800
Microsoft Official courses that were learned in Microsoft Official you know,

31
00:02:09,319 --> 00:02:13,080
some learning centers all over the world, so things like

32
00:02:13,240 --> 00:02:17,319
HTML five, programming, working with the apps in Windows eight,

33
00:02:17,439 --> 00:02:22,120
and et cetera, et cetera. Should I say, writing Windows

34
00:02:22,400 --> 00:02:29,479
apps And that's all. I'm also helping in organizing conferences

35
00:02:29,520 --> 00:02:34,120
like Angler up and React next in Israel, so you're

36
00:02:34,520 --> 00:02:38,199
very welcome to come to Israel someday when this Corona

37
00:02:38,199 --> 00:02:40,039
crisis will end.

38
00:02:40,680 --> 00:02:41,080
Speaker 6: Nice.

39
00:02:41,560 --> 00:02:45,719
Speaker 2: And also you organize the Javaskirt Israel meetup group.

40
00:02:46,599 --> 00:02:49,800
Speaker 4: I'm one of the organizers. I can say that I'm

41
00:02:50,000 --> 00:02:54,879
organizing all the meetups. But you're managing the content team,

42
00:02:54,919 --> 00:02:58,400
and I'm in part of the content team. So yeah,

43
00:02:58,439 --> 00:02:58,960
this is.

44
00:02:58,919 --> 00:03:03,439
Speaker 2: How I knew that. Okay, So thanks, And so today's

45
00:03:03,439 --> 00:03:10,120
topic is about profiling, right, so it will be amazing

46
00:03:10,400 --> 00:03:13,560
if we'll talk about first the problems that we need

47
00:03:13,599 --> 00:03:19,000
profiling for to solve, and then you could take us

48
00:03:19,039 --> 00:03:19,439
through a.

49
00:03:19,479 --> 00:03:22,439
Speaker 6: Journey maybe, like let's first talk about like what is

50
00:03:22,479 --> 00:03:25,960
profiling like what is what does it given me?

51
00:03:26,400 --> 00:03:30,800
Speaker 4: So think about yourself as a CSI guy or a girl,

52
00:03:31,280 --> 00:03:36,919
and the idea of profiling is to find problems problems

53
00:03:36,919 --> 00:03:41,599
that you might have. But if we're talking more exactly

54
00:03:42,159 --> 00:03:46,759
about development, then most of the time when we're talking

55
00:03:46,759 --> 00:03:54,159
about profiling, we're talking about profiling or finding bottlenecks, memory leaks,

56
00:03:54,199 --> 00:03:57,960
and things like that. So we are trying to understand

57
00:03:58,400 --> 00:04:03,560
problems that we have in our software, and by finding

58
00:04:03,599 --> 00:04:08,319
those problems we and solving them, we may improve the

59
00:04:08,360 --> 00:04:13,400
performance of our application, either with the memory consumption of

60
00:04:13,400 --> 00:04:19,920
the application or how fast we ship frames to the screen.

61
00:04:20,360 --> 00:04:25,600
Speaker 2: Also, so that's an amazing analogy. Okay, we're a CSI

62
00:04:25,920 --> 00:04:31,120
team here. Okay, people, now, now we have a problem

63
00:04:31,120 --> 00:04:33,480
where we are in the crimes and what do we see?

64
00:04:33,519 --> 00:04:35,680
What are the problems that we need to profile.

65
00:04:36,319 --> 00:04:39,879
Speaker 4: So most of the time, when we are not seeing

66
00:04:39,920 --> 00:04:45,360
the problems, we will find the problems by our users.

67
00:04:45,680 --> 00:04:47,839
What I mean by that, most of the time when

68
00:04:47,879 --> 00:04:51,759
I'm coming to companies, I'm coming and helping as a

69
00:04:51,759 --> 00:04:58,279
consultant because the users are renting about bad performance, either

70
00:04:58,480 --> 00:05:04,000
because they used app in a device with slow CPU

71
00:05:04,279 --> 00:05:08,600
or they use your your app in a web browser,

72
00:05:08,720 --> 00:05:14,639
that is in some you know, mobile phone or tablet

73
00:05:14,839 --> 00:05:20,560
or whatever, and they're complaining that things aren't working, things

74
00:05:20,560 --> 00:05:24,639
are creaking. You have junk with a not with you,

75
00:05:25,480 --> 00:05:32,319
meaning that when frames are shipped to the screen. We

76
00:05:32,439 --> 00:05:36,079
have a screen rate of sixty frames per second, and

77
00:05:36,160 --> 00:05:40,240
if you go below that frame rate, then you will

78
00:05:40,279 --> 00:05:43,920
have quirks in your animation, in your UI, in everything.

79
00:05:44,600 --> 00:05:49,120
So the idea is to make your patients fast and

80
00:05:49,240 --> 00:05:53,839
fluid and that the users won't complain. What I'm suggesting

81
00:05:54,399 --> 00:05:58,959
mostly for companies is to add development in the development cycles.

82
00:05:59,360 --> 00:06:05,360
Also performance or should I say profiling or performance cycles

83
00:06:05,360 --> 00:06:09,319
means that add those cycles to the development phase and

84
00:06:09,360 --> 00:06:14,759
not to the you know, maintenance when when the users

85
00:06:14,759 --> 00:06:18,519
are complaining, find the problems before they are created?

86
00:06:19,040 --> 00:06:20,199
Speaker 2: Wait, how do you do that?

87
00:06:20,560 --> 00:06:21,680
Speaker 4: How do you do what?

88
00:06:22,000 --> 00:06:24,439
Speaker 6: How do you how do you find the problems before

89
00:06:24,439 --> 00:06:25,040
they're created?

90
00:06:25,480 --> 00:06:30,560
Speaker 4: As I said, add pro filing cycles to your development phase.

91
00:06:30,879 --> 00:06:34,519
What I mean by that is but okay, So the

92
00:06:34,600 --> 00:06:38,839
idea is as following you can take There is a

93
00:06:39,040 --> 00:06:45,720
profiling process that is very very profound. What what you're

94
00:06:45,759 --> 00:06:49,600
doing that process is the following You establish some baseline.

95
00:06:50,160 --> 00:06:54,600
That means that you're creating a branch to your application

96
00:06:55,040 --> 00:06:59,720
or something like that, and you're working in incognitum mode

97
00:06:59,759 --> 00:07:04,839
for example, not affect the performance of the application by

98
00:07:05,199 --> 00:07:09,480
outer means like extensions in the browser or things like that.

99
00:07:09,920 --> 00:07:14,480
After you establish that baseline, you start the profiling process,

100
00:07:14,879 --> 00:07:19,480
which is the process is collect the data. You're collecting

101
00:07:19,480 --> 00:07:25,399
the data using probably your developer tools from developer tools

102
00:07:25,439 --> 00:07:29,199
Firebag in Mozilla or whatever you like. You collect the

103
00:07:29,319 --> 00:07:33,279
data using those tools, and then you analyze the results.

104
00:07:33,639 --> 00:07:37,839
If you're analyzing the results and you find some problems,

105
00:07:38,199 --> 00:07:41,959
and you will find problems probably, then you tune up

106
00:07:41,959 --> 00:07:44,560
the application. What I mean by that you try to

107
00:07:44,680 --> 00:07:48,839
solve the problems, the bottlenecks that you find by adjusting

108
00:07:48,959 --> 00:07:54,720
your algorithms or thinking about how to improve the loops

109
00:07:54,759 --> 00:07:58,079
that you've created or things like that. Once you finish

110
00:07:58,319 --> 00:08:02,079
tuning up the application, test and measure. You test if

111
00:08:02,160 --> 00:08:06,160
the tune up worked or not, and then you continue

112
00:08:06,199 --> 00:08:10,920
on collecting data, analyzing, tuning and testing and measuring. Then

113
00:08:10,959 --> 00:08:14,240
this is the profiling process. That process helps you to

114
00:08:14,639 --> 00:08:20,160
understand how if there are bottlenecks or performance problems, and

115
00:08:20,279 --> 00:08:25,079
then find them and probably or should I say, hopefully,

116
00:08:25,319 --> 00:08:30,720
solve them before they are shipped into the world of

117
00:08:30,879 --> 00:08:31,879
your users.

118
00:08:32,279 --> 00:08:34,639
Speaker 3: And maybe you're going to talk about this later, but

119
00:08:34,840 --> 00:08:40,080
how would you integrate this in your continuous delivery or

120
00:08:40,120 --> 00:08:44,600
continuous integration? Which parts could be automated? Which parts? Which

121
00:08:44,639 --> 00:08:48,799
part would you recommend to automate or to not automate

122
00:08:48,960 --> 00:08:50,639
or just let's not care about automation.

123
00:08:51,720 --> 00:08:57,000
Speaker 4: I'm carrying about automation, and that's a good question. Unfortunately,

124
00:08:57,039 --> 00:09:00,320
most of the tools that we are using to file

125
00:09:00,360 --> 00:09:05,720
applications are the developer tools. You can do that through puppeteer,

126
00:09:05,840 --> 00:09:10,399
but I don't think that there is a solution that

127
00:09:10,600 --> 00:09:15,360
automates this process, okay, or most of the time when

128
00:09:15,840 --> 00:09:20,240
you're doing that process, it's manually. And that's an idea

129
00:09:20,440 --> 00:09:25,279
for finding or tracking things. Maybe someone who listening to

130
00:09:25,360 --> 00:09:29,159
us will take that globe that you throw it my

131
00:09:29,320 --> 00:09:34,879
face and start thinking about how to add profiling processes

132
00:09:35,480 --> 00:09:41,039
in CI. That's an interesting idea. Have you learned or

133
00:09:41,120 --> 00:09:43,200
do you know a tool that is doing that?

134
00:09:43,919 --> 00:09:46,759
Speaker 3: No, really, I know that there's a way of adding

135
00:09:47,120 --> 00:09:51,720
lighthouse to your CI. Never never dived into that, but

136
00:09:52,159 --> 00:09:53,600
I think it's going to be limited. It's going to

137
00:09:53,600 --> 00:09:57,679
be just some monitoring, not real profiling and aware of anything.

138
00:09:58,279 --> 00:10:03,240
Speaker 4: Lighthouse is cool and I'm using it a lot to

139
00:10:03,279 --> 00:10:08,440
start finding problems, but the real problems you won't find

140
00:10:08,480 --> 00:10:12,240
with Lighthouse. You will find how many HTDP requests your

141
00:10:12,919 --> 00:10:17,399
app or your web pages are doing, and some suggestions

142
00:10:17,480 --> 00:10:23,559
of how to to make image optimizations or other stuff,

143
00:10:23,600 --> 00:10:28,799
But the hardcore bottlenecks you won't be able to find

144
00:10:28,840 --> 00:10:34,320
with Lighthouse. So this is not an ideal tool for that.

145
00:10:34,440 --> 00:10:37,200
But I know that you can add Lighthouse to your

146
00:10:37,639 --> 00:10:44,879
your CI and monitor static, monitor your web pages, or

147
00:10:44,919 --> 00:10:45,759
your way back.

148
00:10:46,360 --> 00:10:49,480
Speaker 6: So it's like Lighthouse is a way to get started,

149
00:10:49,519 --> 00:10:52,679
but it's not a way to like find the deeper issues,

150
00:10:52,759 --> 00:10:53,360
is what you're saying.

151
00:10:54,360 --> 00:10:57,639
Speaker 4: It's when we're talking about deeper issues, we need to

152
00:10:57,720 --> 00:11:01,919
understand how things are working in the browser, and for

153
00:11:02,039 --> 00:11:05,279
that when we need to understand how pixel pipeline is working,

154
00:11:05,960 --> 00:11:12,399
and how where the browser is shipping the frames to

155
00:11:12,519 --> 00:11:18,519
the device screen, and what should we do in order

156
00:11:18,600 --> 00:11:23,200
to increase performance or what should we avoid in order

157
00:11:23,279 --> 00:11:26,559
to increase our web page performance.

158
00:11:27,720 --> 00:11:30,840
Speaker 7: As a scenario for you, and it may or may

159
00:11:30,879 --> 00:11:33,679
not be based on a true story. Say I'm working

160
00:11:33,720 --> 00:11:40,320
on a large application and it has suffers from major

161
00:11:40,440 --> 00:11:43,960
performance issues. I know that I know that the performance

162
00:11:44,039 --> 00:11:47,639
is really bad. Where do I even begin to try

163
00:11:47,679 --> 00:11:49,320
and figure out what is causing that?

164
00:11:49,879 --> 00:11:55,080
Speaker 4: So the first suggestion is open your Chrome debtols, then

165
00:11:55,159 --> 00:11:59,320
go to profile to performance stub, and in the performance

166
00:11:59,360 --> 00:12:05,039
stub and start recording your interaction with the application. Once

167
00:12:05,080 --> 00:12:08,000
you stop the recording, you will get the timeline with

168
00:12:08,120 --> 00:12:11,519
a lot of information that you can use in order

169
00:12:11,559 --> 00:12:17,000
to analyze the problems. Sometimes the Chrome is a Chrome

170
00:12:17,039 --> 00:12:20,720
profiler is very smart and it will give you hints

171
00:12:21,080 --> 00:12:25,440
like red squares or things like that, or will shout

172
00:12:25,519 --> 00:12:28,080
at you that you have a lot of v flows,

173
00:12:28,600 --> 00:12:33,799
which is something that I might mention later on. And

174
00:12:33,960 --> 00:12:39,679
when you're analyzing those this timeline and all the things

175
00:12:39,720 --> 00:12:43,360
inside of it, then you will be able to pinpoint

176
00:12:43,559 --> 00:12:47,399
some parts of the applications that aren't performing very well,

177
00:12:47,840 --> 00:12:51,960
and then you will be able to tune it those

178
00:12:52,000 --> 00:12:56,639
problem problems at first, and later on, once you will

179
00:12:56,679 --> 00:12:59,519
do this cycle again and again and again and again,

180
00:13:00,159 --> 00:13:04,639
then you will be able to increase the performance. So

181
00:13:04,799 --> 00:13:09,080
the idea is just open your Chrome their tools Profile,

182
00:13:09,360 --> 00:13:15,519
Performance set tub and run some diagnostics later on. So

183
00:13:15,600 --> 00:13:19,399
of those problems that you see and continue in doing

184
00:13:19,440 --> 00:13:22,480
those cycles again and again and again and increase your performance.

185
00:13:22,879 --> 00:13:26,960
This is something that might sound cumbersome. It is, but

186
00:13:27,679 --> 00:13:30,559
the gain is very good. The gain is very fast.

187
00:13:30,639 --> 00:13:35,039
You get a gain very fast. For example, did something

188
00:13:35,159 --> 00:13:40,279
like that in a web application. It was three years ago.

189
00:13:40,840 --> 00:13:44,799
They called me because they had a severe performance problem

190
00:13:45,039 --> 00:13:48,679
in some web page that they had specific web page.

191
00:13:49,200 --> 00:13:54,600
Got to know that. The company started recording profiling, found

192
00:13:54,600 --> 00:13:59,480
the problem and it was stupid problem because most of

193
00:13:59,519 --> 00:14:05,919
the problem that caused performance issues mainly that they're not smart.

194
00:14:06,840 --> 00:14:10,919
The problem was the registered sum event handler that was

195
00:14:10,960 --> 00:14:16,320
repeated and repeated and repeated very very fast. So the

196
00:14:16,799 --> 00:14:27,200
page performance was degraded. And once we find found the problem,

197
00:14:27,360 --> 00:14:30,600
and it was like twenty minutes after I arrived to

198
00:14:30,639 --> 00:14:34,480
the customer, we solved it. It took one hour to

199
00:14:34,559 --> 00:14:39,799
solve the problem, and I wasted the full consulting day

200
00:14:40,039 --> 00:14:44,120
in one hour and thirty minutes, and they paid for

201
00:14:45,000 --> 00:14:48,440
one hour and thirty minutes instead of eight hours that

202
00:14:48,440 --> 00:14:51,399
they were supposed to pay. As they said, you solved

203
00:14:51,440 --> 00:14:52,639
the problem very fast.

204
00:14:53,960 --> 00:14:56,320
Speaker 7: So what you're saying is that the trick is to

205
00:14:56,399 --> 00:15:00,360
identify the problem and then beat around the bush maybe

206
00:15:00,399 --> 00:15:07,519
seven hours, and I go, ah, I've just found it

207
00:15:07,879 --> 00:15:10,799
conveniently five minutes before I'm due to invoice you.

208
00:15:12,000 --> 00:15:15,919
Speaker 4: No, I'm not doing that. It will hurt, It will

209
00:15:16,080 --> 00:15:20,360
hurt my reputation. I was very happy that I solved

210
00:15:20,399 --> 00:15:25,399
it so fast because they were complaining that the app

211
00:15:25,559 --> 00:15:29,120
is such a huge thing and they can't go to

212
00:15:29,279 --> 00:15:34,159
production with it. That was that was funny. But yes,

213
00:15:34,759 --> 00:15:36,919
there are a lot of stories like that that you

214
00:15:37,320 --> 00:15:42,120
you might find the performance problems very fast and solve

215
00:15:42,159 --> 00:15:46,440
them very fast, and sometimes it is very elusive to

216
00:15:46,559 --> 00:15:52,159
find the bugs that were created and creating the performance problems.

217
00:15:52,279 --> 00:15:56,000
And with those times it might take a couple of

218
00:15:56,039 --> 00:16:01,600
hours or even days to identify the problem. As we started,

219
00:16:02,159 --> 00:16:08,799
we are CSI investigators. Sometimes your murder seen tells you everything.

220
00:16:09,080 --> 00:16:10,600
Sometimes it's not.

221
00:16:11,600 --> 00:16:15,279
Speaker 8: As far as Anguler goes. What's like the biggest obviously

222
00:16:15,320 --> 00:16:18,720
not unsubscribing to observables, right, but what else is there

223
00:16:18,759 --> 00:16:23,080
that causes large memory leaks or obvious ones that first of.

224
00:16:23,039 --> 00:16:28,440
Speaker 4: All, you mentioned the obvious observables are the biggest thing

225
00:16:28,559 --> 00:16:33,399
that can help you lick like like a ship that

226
00:16:33,600 --> 00:16:39,120
is drowning. Because if you're not releasing those observables and

227
00:16:39,159 --> 00:16:42,840
you're moving from one page to another, that is a problem.

228
00:16:43,240 --> 00:16:46,720
That is the problem that will raise its ugly head

229
00:16:47,120 --> 00:16:50,679
very soon. And I had a story of such a

230
00:16:50,759 --> 00:16:56,080
problem two months ago in a company that they created

231
00:16:56,240 --> 00:17:00,919
something very sophisticated and they didn't release an observdvable and

232
00:17:01,039 --> 00:17:03,840
every time that they moved from one page to another,

233
00:17:04,480 --> 00:17:08,960
that of observable included something like thirty five megabytes of

234
00:17:09,240 --> 00:17:13,599
data and when you return to that page and move

235
00:17:13,640 --> 00:17:18,119
again and return and move, you get spikes of memory lick.

236
00:17:21,000 --> 00:17:25,599
And then they said something like, we have spikes of

237
00:17:25,759 --> 00:17:29,119
thirty five megabytes. We don't understand where are they coming

238
00:17:29,119 --> 00:17:32,039
from or why they are coming from. And this was

239
00:17:32,119 --> 00:17:38,720
from ANGI rex store with index dB combination. And once

240
00:17:38,799 --> 00:17:44,079
we unidentify those problems, we solved them. So observables are

241
00:17:44,400 --> 00:17:51,480
mainly one problem. Another problem is change detection in Angular.

242
00:17:52,359 --> 00:17:56,400
If you're not familiar with on push sometimes you can

243
00:17:56,519 --> 00:18:00,720
cause various severe performance problems if you have a lot

244
00:18:00,759 --> 00:18:09,119
of elements or for Star for eng four or things

245
00:18:09,160 --> 00:18:13,319
like that, that you're replicating some elements in the dome.

246
00:18:14,000 --> 00:18:19,519
If you're taking or doing things outside of anger angler

247
00:18:19,599 --> 00:18:22,319
is not aware of the things you're doing outside if

248
00:18:22,359 --> 00:18:27,680
you're using ANGI zone. So this might cause performance problems

249
00:18:28,559 --> 00:18:33,160
of course animations when you're creating. When we are creating animations,

250
00:18:33,200 --> 00:18:38,200
this if you know, we are not shipping frames to

251
00:18:38,279 --> 00:18:42,720
the SCREM below ten milliseconds. This is the rule of

252
00:18:42,799 --> 00:18:47,079
thumb for animation. You need ten milliseconds for each frame.

253
00:18:47,160 --> 00:18:51,319
If it's not. If it's if you're doing something in

254
00:18:51,440 --> 00:18:56,480
eleven milliseconds, then you might miss a frame and then

255
00:18:56,640 --> 00:19:01,039
the performance of the elimation will be sluggish. Bit so

256
00:19:02,079 --> 00:19:06,000
it's not the sixteen milliseconds that everybody's talking about, because

257
00:19:06,039 --> 00:19:10,160
you have something like five to six milliseconds of overhead

258
00:19:10,279 --> 00:19:15,319
that the browser and the operation system is doing underneath.

259
00:19:15,400 --> 00:19:22,079
So ten milliseconds or sluggish animation. So these are the

260
00:19:22,160 --> 00:19:26,279
main things that I can see in angular applications. Mostly

261
00:19:26,799 --> 00:19:33,000
either it's observables or combinations of libraries that people are

262
00:19:33,119 --> 00:19:37,079
using and not using in the standout way. Let's say

263
00:19:37,240 --> 00:19:43,039
let's say that thing or things like animations that they're

264
00:19:43,119 --> 00:19:49,519
creating and shipping frames be more than one sort milliseconds

265
00:19:49,519 --> 00:19:50,279
and things like that.

266
00:19:50,680 --> 00:19:53,240
Speaker 3: My question is quite related, but it comes like it's

267
00:19:53,480 --> 00:19:56,359
in commission with this is like, you know, in security,

268
00:19:56,400 --> 00:19:59,839
there is this o ass top ten of security risks.

269
00:20:00,240 --> 00:20:04,119
What would be like the top three of performance risks?

270
00:20:04,160 --> 00:20:07,319
Like if we have to have like a top three,

271
00:20:08,519 --> 00:20:12,920
what let's sort them by by taking into account like

272
00:20:13,160 --> 00:20:16,440
the frequency they appear and the impact Also like which

273
00:20:16,480 --> 00:20:21,160
one like is the one you see that breaks apps?

274
00:20:21,240 --> 00:20:26,079
Speaker 4: You know, large data sources. That's that's the main thing

275
00:20:26,160 --> 00:20:30,319
that breaks ups large data sources. This is why there

276
00:20:30,319 --> 00:20:35,160
are solutions out there, like out there like infinite scrolling

277
00:20:35,440 --> 00:20:42,119
or virtualization, virtual scrolling or even filters for big data sets.

278
00:20:42,519 --> 00:20:46,599
Once you are not aware that the amount of elements

279
00:20:46,640 --> 00:20:50,400
that are created for each and every item in your

280
00:20:50,640 --> 00:20:55,279
array might affect the performance of your web page, then

281
00:20:55,960 --> 00:21:01,359
then you're creating a very non performance application or web page.

282
00:21:01,680 --> 00:21:06,960
So the main thing is understanding that large datasets or

283
00:21:07,160 --> 00:21:11,640
large data is something that you need to handle very carefully.

284
00:21:12,079 --> 00:21:16,319
This is something that I had in an application that

285
00:21:16,400 --> 00:21:21,000
I'm creating. These days, we have a very big data

286
00:21:21,039 --> 00:21:28,319
set of patients coronavirus patients and helping the Israeli government

287
00:21:28,519 --> 00:21:33,599
health department, and we have a lot of people who

288
00:21:33,640 --> 00:21:37,319
got infected. So how do you create an app with

289
00:21:37,960 --> 00:21:42,920
something like currently we have sixteen thousand people which were

290
00:21:42,920 --> 00:21:46,960
affected by the coronavirus here in Israel, and so how

291
00:21:47,000 --> 00:21:51,279
do you show all these data through your application? So

292
00:21:51,440 --> 00:21:55,920
the solution that we used was adding over filtering data

293
00:21:56,519 --> 00:22:00,680
and never show all the data all the time, because

294
00:22:01,319 --> 00:22:04,839
if you're going to show all the data, your application

295
00:22:05,079 --> 00:22:10,319
performance will break. Because for each patient, we have something

296
00:22:10,480 --> 00:22:16,440
like seven to ten elements in the dome. So take

297
00:22:16,559 --> 00:22:21,880
those ten elements for example, multiply them with sixteen thousand,

298
00:22:22,720 --> 00:22:27,079
and there is a threshold that the browser will can't

299
00:22:27,119 --> 00:22:34,480
handle so many elements simultaneously. So large data sources or

300
00:22:34,599 --> 00:22:38,599
large data sets should be handled very carefully. They are

301
00:22:38,640 --> 00:22:43,039
also the main thing that creates memory leaks. Later on,

302
00:22:43,599 --> 00:22:48,359
if you're using large, large data sets or data sources,

303
00:22:48,480 --> 00:22:54,440
then you're up will leak probably because of those data sources.

304
00:22:55,000 --> 00:22:59,759
So this is the the number one problem of performance problem.

305
00:23:00,640 --> 00:23:03,599
Should we continue to number two? Oh?

306
00:23:03,759 --> 00:23:04,559
Speaker 6: What's number two?

307
00:23:06,079 --> 00:23:11,400
Speaker 4: Number two is understanding the platform that you work in.

308
00:23:12,440 --> 00:23:17,880
There are ways to create applications. Each and every platform

309
00:23:18,039 --> 00:23:23,400
has its own constant pros. For example, if we're creating

310
00:23:23,599 --> 00:23:29,200
Angular applications. We are creating application using Angular framework and

311
00:23:29,400 --> 00:23:35,039
Angler is abstruction over them manipulation. So if we don't

312
00:23:35,119 --> 00:23:38,559
understand how Angler work, and this is something that I

313
00:23:38,640 --> 00:23:42,799
suggest every time, understand the tool that you're using, then

314
00:23:43,039 --> 00:23:48,920
we might cause performance problems. Who remember the magic thing

315
00:23:49,039 --> 00:23:54,519
in eng four in Angular one when you're creating Angular one,

316
00:23:55,039 --> 00:23:58,319
there was a magic thing a filter that you're going

317
00:23:58,400 --> 00:24:02,519
to put in Engine four to make it more performance.

318
00:24:03,200 --> 00:24:05,839
Speaker 6: Filter in Angular JS for enery.

319
00:24:08,039 --> 00:24:09,000
Speaker 4: An energie repeat.

320
00:24:09,200 --> 00:24:13,440
Speaker 3: Yeah, oh yeah, No, it wasn't Angler adding a hash

321
00:24:13,440 --> 00:24:16,839
to your item to track your items with the hash

322
00:24:17,079 --> 00:24:19,640
if your data was in memory, but if you needed

323
00:24:19,640 --> 00:24:20,720
a track by otherwise.

324
00:24:21,079 --> 00:24:27,640
Speaker 4: So there was a thing in Angular a known performance

325
00:24:27,839 --> 00:24:33,799
problem that you could solve in the in their change detection.

326
00:24:34,519 --> 00:24:39,400
You just had to make indexes on the objects that

327
00:24:39,480 --> 00:24:43,960
you're using. So I don't remember what it was we're

328
00:24:44,000 --> 00:24:47,720
talking about four or five years ago, but every time

329
00:24:47,759 --> 00:24:50,519
that I got to customer and they're working with the

330
00:24:50,559 --> 00:24:54,839
Angular gs and they developers didn't know that you could

331
00:24:55,079 --> 00:25:02,319
put the key on the engine repeat and then get

332
00:25:02,440 --> 00:25:07,400
better performance by understanding how the platform is working. So

333
00:25:08,119 --> 00:25:13,759
that's that's the second problem. Second problem with performance is us.

334
00:25:14,200 --> 00:25:19,039
We are creating those the performance problems by not understanding

335
00:25:19,079 --> 00:25:23,039
how things work. So this is me suggesting to open

336
00:25:23,200 --> 00:25:28,440
the engine, who then just see how the engine is working.

337
00:25:30,000 --> 00:25:34,440
Speaker 3: That's true, and though sometimes going to be relocated. But

338
00:25:34,519 --> 00:25:37,319
then I have a question about that, like there are

339
00:25:37,400 --> 00:25:40,880
so many things here to check out. But as you

340
00:25:40,920 --> 00:25:45,440
said before, some issues can be solved in like half

341
00:25:45,440 --> 00:25:48,680
an hour because it's just a listener to remove or

342
00:25:49,079 --> 00:25:53,279
or non subscribe to a subscription channle or a track

343
00:25:53,359 --> 00:25:55,599
by to add on ENG four or something like that.

344
00:25:56,039 --> 00:26:02,640
But some performance issues but money lots of refacturing. So

345
00:26:03,319 --> 00:26:07,119
which kind of issues are those and what are the

346
00:26:07,160 --> 00:26:10,359
things that we should be careful about since the beginning

347
00:26:10,440 --> 00:26:13,279
because otherwise can be very expensive to fix them.

348
00:26:13,759 --> 00:26:19,559
Speaker 4: So we need to understand how the main problems that

349
00:26:20,000 --> 00:26:25,359
can be caused by repaints and reflows. What is a reflow?

350
00:26:25,880 --> 00:26:29,480
Reflow is a process in the browser that the browser

351
00:26:29,559 --> 00:26:32,519
is triggering from time to time and it will be

352
00:26:32,599 --> 00:26:36,920
triggered by manipulation of the dome. So for example, if

353
00:26:36,920 --> 00:26:40,519
we are adding an element, we're moving an element, or

354
00:26:40,759 --> 00:26:46,839
we're changing the layout of the web page, reflow can

355
00:26:46,920 --> 00:26:53,240
be triggered the browsers try to optimize this process, and

356
00:26:53,920 --> 00:26:56,799
this is something that we need to be aware of. Okay,

357
00:26:56,960 --> 00:27:01,119
so if we're touching the dome, this is the main

358
00:27:01,720 --> 00:27:06,200
thing that might cause a reflow, and the reflow is

359
00:27:06,359 --> 00:27:11,200
expensive in terms of performance. Second thing that that I

360
00:27:11,279 --> 00:27:15,480
said is repaint. In repaint, we change the color of

361
00:27:15,640 --> 00:27:21,599
some element, we change the font size, things like that.

362
00:27:22,160 --> 00:27:26,240
Those things can cause a repaint. Browser is repainting the

363
00:27:26,400 --> 00:27:29,920
entire screen or in a section in the screen. This

364
00:27:30,079 --> 00:27:34,599
is less expensive than reflow. But when when we understand

365
00:27:34,599 --> 00:27:39,599
that changes in the dome or changes in that causes

366
00:27:39,880 --> 00:27:45,039
painting are the main things that can impact the performance

367
00:27:45,079 --> 00:27:50,039
of our page, then we try to minimize those impacts

368
00:27:50,079 --> 00:27:56,160
by the combining or doing bulk changes, or doing bulk

369
00:27:56,319 --> 00:28:00,400
cess changes, or things like that, things that were done

370
00:28:00,480 --> 00:28:03,720
in jaquer in the past and are being done by

371
00:28:04,079 --> 00:28:08,680
for example, in React by virtual Dome, that bulk change

372
00:28:09,480 --> 00:28:13,240
is shipped to the dome or to the dome itself,

373
00:28:13,759 --> 00:28:17,599
or in Angular in IVY, there are a lot of

374
00:28:18,039 --> 00:28:23,519
changes that they did to make things, make bulk changes

375
00:28:23,640 --> 00:28:27,720
or things like that to happen in order to avoid

376
00:28:27,839 --> 00:28:32,880
those bigger not big, but a lot of reflows and

377
00:28:33,000 --> 00:28:38,359
repaints that the browser might trigger. As developers, we aren't

378
00:28:39,160 --> 00:28:42,720
or we can't affect when a reflow or repaint will happen.

379
00:28:43,240 --> 00:28:48,039
But we should understand that these processes are happening and

380
00:28:48,319 --> 00:28:53,480
the browser is doing those processes, and what triggers those

381
00:28:53,519 --> 00:28:57,000
processes is the important thing. So once can understand that

382
00:28:57,400 --> 00:29:03,319
we what triggers the the processes and avoid triggering those

383
00:29:03,359 --> 00:29:08,319
processes a lot more repeatedly than we will be able

384
00:29:08,400 --> 00:29:13,160
to affect the performance of our application or web page. Yeah,

385
00:29:13,880 --> 00:29:18,759
any other questions from the funelists or you're in shock.

386
00:29:19,720 --> 00:29:20,599
Speaker 3: We are repainting.

387
00:29:22,039 --> 00:29:25,799
Speaker 4: This is something I did three weeks ago. When you

388
00:29:25,880 --> 00:29:28,400
have a lot of spare time at at your home

389
00:29:28,440 --> 00:29:33,599
because of social distancing, you repaint well.

390
00:29:33,640 --> 00:29:36,599
Speaker 6: Thank you Gil for going over profiling with us and

391
00:29:37,079 --> 00:29:39,839
basically what it is and how we can do it

392
00:29:39,839 --> 00:29:42,680
better in our Angular applications. Do you guys have any

393
00:29:42,720 --> 00:29:46,200
more questions before I move on to picks and how

394
00:29:46,200 --> 00:29:47,559
we can find you online?

395
00:29:47,920 --> 00:29:53,480
Speaker 3: I had a little question, Sorry for that, get into it.

396
00:29:54,000 --> 00:29:59,880
So there are some features in Angular that help us

397
00:30:00,200 --> 00:30:04,160
detect performance issues, but quite late, but you know, I'm

398
00:30:04,160 --> 00:30:07,759
thinking about the budgets. You know, for example, that tells

399
00:30:07,799 --> 00:30:09,599
you when your files are too big, or maybe because

400
00:30:09,599 --> 00:30:13,119
you included like a huge styles or stuff like that.

401
00:30:13,799 --> 00:30:16,119
And I think there's a lot of there are a

402
00:30:16,160 --> 00:30:18,240
lot of things to add to these kind of features.

403
00:30:18,240 --> 00:30:22,119
But what what kind of things you can think about

404
00:30:22,160 --> 00:30:25,640
that we should add or some simple things we could

405
00:30:25,960 --> 00:30:29,640
add to our projects, like I don't know, like detect

406
00:30:30,039 --> 00:30:34,759
slow unit tests or things like that that can detect

407
00:30:35,000 --> 00:30:37,359
some performance issues. What kind of alerts I can have,

408
00:30:37,440 --> 00:30:39,079
Like I have a huge project, I don't want, I

409
00:30:39,119 --> 00:30:40,880
don't have time to dive into it. What kind of

410
00:30:40,920 --> 00:30:44,440
thing I can plug in it and get some indicators?

411
00:30:44,599 --> 00:30:47,119
Doesn't mean there's a performance issue, but you know something

412
00:30:47,160 --> 00:30:48,960
that can pop up here and there.

413
00:30:49,519 --> 00:30:55,640
Speaker 4: There are monitoring tools that you can use on your applications.

414
00:30:56,079 --> 00:30:58,680
You mentioned one of them which is Lighthouse, and you

415
00:30:58,720 --> 00:31:02,440
can add it to the eye process. There are the

416
00:31:02,960 --> 00:31:07,440
idea of window, those performance objects that you can use

417
00:31:07,920 --> 00:31:12,079
in order to monitor by yourself. This is something that

418
00:31:12,160 --> 00:31:17,599
you can plug your your code into it. You get

419
00:31:17,680 --> 00:31:23,240
the performance object and you analyze the performance of the

420
00:31:23,279 --> 00:31:27,200
web page by yourself or through puppeteer or things like that.

421
00:31:27,599 --> 00:31:32,319
But there is no magic tool that you can row

422
00:31:33,359 --> 00:31:39,359
into your application and find performance problems. Because problems are

423
00:31:39,519 --> 00:31:45,400
created by developers, and because of that, it's very hard

424
00:31:45,519 --> 00:31:48,319
to create a tool. No, it's not a very hard

425
00:31:48,480 --> 00:31:51,200
thing to create it too, but there aren't a lot

426
00:31:51,240 --> 00:31:54,920
of good tools to analyze performance problems or to add

427
00:31:55,039 --> 00:31:59,559
to your angler application in code that in order to

428
00:31:59,720 --> 00:32:03,920
money toward your performance. You can use Lighthouse as I said,

429
00:32:04,000 --> 00:32:09,799
you can use Google Analytics to analyze things about about

430
00:32:10,079 --> 00:32:17,720
your applications and all those monitor application that adds code

431
00:32:17,839 --> 00:32:22,440
to your application, monitors your application, but because of that

432
00:32:22,640 --> 00:32:27,039
degrade your performance a little bit. So either you do

433
00:32:27,119 --> 00:32:31,880
it by yourself using the Window Doot Performance object, or

434
00:32:32,759 --> 00:32:37,279
you can even use some outside tool. But there is

435
00:32:37,319 --> 00:32:42,559
no something like a model that you can plug and

436
00:32:42,720 --> 00:32:47,839
play with it to monitor your application, not that I'm

437
00:32:47,920 --> 00:32:48,359
aware of.

438
00:32:49,240 --> 00:32:53,279
Speaker 3: That's cool. So, but maybe like using the performance tool

439
00:32:53,440 --> 00:32:59,160
to the Window performance to monitor some functions and for

440
00:32:59,720 --> 00:33:02,480
maybe unit tests can be like a starting point. Like

441
00:33:02,519 --> 00:33:04,880
I'm going to just function is doing a lot of

442
00:33:04,920 --> 00:33:07,920
fork Let's see if it's not slowing down through the time.

443
00:33:07,960 --> 00:33:10,480
Maybe that can be You will have to.

444
00:33:11,960 --> 00:33:17,640
Speaker 4: Run to create a timer that you start running the

445
00:33:17,720 --> 00:33:20,319
timer at the beginning and in the end. I did

446
00:33:20,319 --> 00:33:25,559
that a few times in the past for some company

447
00:33:25,640 --> 00:33:33,039
that created some analytics to understand the performance issues before death.

448
00:33:33,759 --> 00:33:39,640
The Chrome dev tools did it for me. So you

449
00:33:39,680 --> 00:33:44,319
can create those, but most most of the time you

450
00:33:44,359 --> 00:33:51,680
will just need to add some profiling processes your development process.

451
00:33:51,880 --> 00:33:53,759
As I said, just a suggestion.

452
00:33:54,599 --> 00:33:54,839
Speaker 7: Cool.

453
00:33:55,039 --> 00:34:03,960
Speaker 2: Thanks trying to Okay, Hello, hello, so we covered everything.

454
00:34:04,559 --> 00:34:08,840
Anyone still has any questions? Okay, so good time to

455
00:34:08,920 --> 00:34:11,159
go to the pigs, right.

456
00:34:11,960 --> 00:34:15,280
Speaker 6: I have one that is related to what we've been

457
00:34:15,320 --> 00:34:18,079
talking about. And actually the question that you just asked

458
00:34:18,280 --> 00:34:21,679
was I was recently talking with Steven Fluin, who's the

459
00:34:21,719 --> 00:34:26,320
Angular advocate on the Angular team, and he is like,

460
00:34:26,360 --> 00:34:28,159
has this side project I don't know if you've heard

461
00:34:28,159 --> 00:34:33,280
of it called bundlesize dot dev, and it is a

462
00:34:33,400 --> 00:34:36,440
site that he's making currently working on. But you can

463
00:34:36,440 --> 00:34:39,199
go there right now to analyze and benchmark your JavaScript

464
00:34:39,199 --> 00:34:42,159
and type script. So you enter like the URL to

465
00:34:42,199 --> 00:34:44,920
the site that you want to scan, and after like

466
00:34:45,039 --> 00:34:48,280
scanning it, it pulls up like a bunch of numbers

467
00:34:48,320 --> 00:34:51,119
about its bundle size, what version of Angler it's using,

468
00:34:51,519 --> 00:34:54,199
and actually works for non Angular sites as well, So

469
00:34:54,280 --> 00:34:57,039
it's really cool site, and he said, the more that

470
00:34:57,079 --> 00:34:59,000
people use it, the more data he's going to have

471
00:34:59,119 --> 00:35:01,679
to go off of. It basically gives you a score

472
00:35:01,880 --> 00:35:05,559
on all other sites he's ever scanned, and so it's

473
00:35:05,599 --> 00:35:08,880
like your performance or your your size is like around

474
00:35:09,000 --> 00:35:11,719
ninety three percent out of you know, it's faster than

475
00:35:11,920 --> 00:35:15,199
other sites are slower. So it's a really cool little side.

476
00:35:15,000 --> 00:35:17,800
Speaker 3: Project he's got going. So check it out. It's bundlesize

477
00:35:17,880 --> 00:35:18,639
dot dev.

478
00:35:19,159 --> 00:35:19,480
Speaker 4: Nice.

479
00:35:19,800 --> 00:35:20,360
Speaker 3: Thanks.

480
00:35:20,599 --> 00:35:24,000
Speaker 2: Okay, let's go in the same order, Chris, What there

481
00:35:24,000 --> 00:35:24,840
are picks?

482
00:35:25,079 --> 00:35:29,599
Speaker 7: Yeah, I've got two picks today. First one is I've

483
00:35:29,639 --> 00:35:33,480
been working from home now for seven weeks, I think,

484
00:35:33,760 --> 00:35:36,440
and I don't particularly enjoy it. One of the issues

485
00:35:36,480 --> 00:35:38,360
I had when I first started, when we all went

486
00:35:38,400 --> 00:35:42,199
into lockdown is my internet speeds at home. I think

487
00:35:42,400 --> 00:35:45,519
UK internet speeds are a little bit behind other parts

488
00:35:45,519 --> 00:35:48,599
of the world anyway, but I was finding that the

489
00:35:48,679 --> 00:35:52,039
room which has become my home office, I was getting

490
00:35:52,079 --> 00:35:55,239
about one percent one to two percent of the download

491
00:35:55,239 --> 00:35:58,440
speeds that I would get at my router. And also

492
00:35:58,559 --> 00:36:00,920
only one thing could be on WiFi at a time,

493
00:36:01,000 --> 00:36:02,840
so I had to have my phone. I'd have like

494
00:36:02,920 --> 00:36:05,480
my phone just off of Wi Fi. If anyone could

495
00:36:05,480 --> 00:36:07,920
hear my son is just outside the doors. Decided to

496
00:36:07,960 --> 00:36:11,400
bear a little visit as well. Anyway, So I think

497
00:36:11,440 --> 00:36:14,679
my Alexa must have heard me grumbling about this, because

498
00:36:14,719 --> 00:36:18,199
one day on the Amazon homepage, suddenly this thing was

499
00:36:18,239 --> 00:36:21,320
there called an Eero, and I'd never heard of it before,

500
00:36:21,360 --> 00:36:24,480
and yet it was just there mystically on the front page.

501
00:36:24,559 --> 00:36:28,679
And I mean, even as a technologist myself, I have

502
00:36:28,800 --> 00:36:30,679
no idea how this thing works, but I thought I'll

503
00:36:30,679 --> 00:36:33,199
give it a try. And it's just a home mesh

504
00:36:33,320 --> 00:36:36,519
Wi Fi thing, and I bought a couple of them,

505
00:36:36,519 --> 00:36:38,960
but I plugged in one of them. It's literally right

506
00:36:39,000 --> 00:36:41,960
next to the router, and I suddenly had like a

507
00:36:42,559 --> 00:36:44,880
I was getting like ten times the speeds in the

508
00:36:44,920 --> 00:36:48,480
same room that I'm trying to work in. And then

509
00:36:48,519 --> 00:36:51,360
I plugged in a second one, and now I get like,

510
00:36:52,000 --> 00:36:55,679
basically about eighty percent of my of my router speeds

511
00:36:55,719 --> 00:36:58,679
in my home office and everything can be connected at once,

512
00:36:58,760 --> 00:37:01,079
and it's stenders.

513
00:37:01,119 --> 00:37:01,719
Speaker 3: What is it.

514
00:37:01,679 --> 00:37:03,800
Speaker 7: Basically the one that you plug You plug one into

515
00:37:03,800 --> 00:37:06,320
your ridger and it just takes over, like all the

516
00:37:06,400 --> 00:37:08,480
lights on my route are just gone. Off, the ERA

517
00:37:08,679 --> 00:37:11,679
just completely took over it and instantly just boosted everything.

518
00:37:12,079 --> 00:37:14,239
And then when you put additional ones around the house,

519
00:37:14,280 --> 00:37:16,840
it just filters the Wi Fi around. I have no

520
00:37:16,880 --> 00:37:18,719
idea how it works, but it has made my working

521
00:37:18,719 --> 00:37:21,519
from home one hundred percent better. Like I actually I

522
00:37:21,519 --> 00:37:23,519
can I can get on now, which is great. So

523
00:37:23,679 --> 00:37:25,199
Era definitely my recommendation.

524
00:37:25,440 --> 00:37:30,639
Speaker 2: Wow, sounds like what created the coronavirus, the slip conspiracy,

525
00:37:30,719 --> 00:37:32,760
theories of five G and stuff like that.

526
00:37:32,960 --> 00:37:36,239
Speaker 3: Yeah, do you think right here, do you think it

527
00:37:36,280 --> 00:37:38,559
hacks like your neighbor's WiFi or something.

528
00:37:38,960 --> 00:37:39,679
Speaker 4: I have no idea.

529
00:37:40,199 --> 00:37:44,519
Speaker 7: Maybe maybe that's what it does. Maybe I have one

530
00:37:44,559 --> 00:37:48,960
other pick. I like to pick entertaining Twitter accounts to

531
00:37:49,079 --> 00:37:52,119
brighten up people's day. One that I particularly enjoy, especially

532
00:37:52,119 --> 00:37:55,679
in these dark days, is called Grumpy Skeleton, and it's

533
00:37:55,719 --> 00:37:59,960
this guy. He basically tweets as skeletor from but specific

534
00:38:00,639 --> 00:38:03,559
the Skeleton from the nineteen eighties he Man and the

535
00:38:03,599 --> 00:38:06,519
Masters of the Universe cartoon. I will I will give

536
00:38:06,559 --> 00:38:09,920
a little bit of a disclaimer that he's kind of sweary,

537
00:38:10,079 --> 00:38:12,679
So if you don't enjoy the swears in the tweets,

538
00:38:13,320 --> 00:38:14,880
don't go and have a look. But if you're not

539
00:38:14,960 --> 00:38:16,440
bothered by that, I go and have a look. Basically,

540
00:38:16,480 --> 00:38:19,400
every time he tweets, he'll put a he must painstakingly

541
00:38:19,440 --> 00:38:21,800
go through hours and hours of old he Man cartoons

542
00:38:21,840 --> 00:38:24,480
because he puts a still from the cartoon and he'll

543
00:38:24,480 --> 00:38:27,400
just write some amusing thing about how his henchmen are useless,

544
00:38:27,480 --> 00:38:30,320
or how he Man's just an idiot trying to bash

545
00:38:30,360 --> 00:38:32,039
down a door, how he's just trying to take over

546
00:38:32,119 --> 00:38:34,679
Castle gray Scull but he can't because of social distancing

547
00:38:34,719 --> 00:38:38,199
and stuff like that. The Grumpy Skeleton definitely recommend that

548
00:38:38,320 --> 00:38:39,320
those are my picks today.

549
00:38:39,840 --> 00:38:42,519
Speaker 2: Thanks, okay, Eddie, how about you?

550
00:38:43,400 --> 00:38:46,039
Speaker 9: Nice? Well, so I am low on picks down, I

551
00:38:46,079 --> 00:38:49,840
have one, so I'm gonna grab and steal Chris's Eero

552
00:38:50,000 --> 00:38:53,079
one because hero is amazing. I've had mine for like

553
00:38:53,119 --> 00:38:56,280
two years and it's it's awesome, So definitely recommend. I

554
00:38:56,280 --> 00:39:00,000
have a four story townhouse and including like outdoor areas,

555
00:39:00,039 --> 00:39:03,159
and I get perfect Internet like anywhere in the entire

556
00:39:03,239 --> 00:39:07,079
four store townhouse or outside, so it's it's awesome. We

557
00:39:07,119 --> 00:39:12,480
have three euroboxes that'll communicate, so that is great. And

558
00:39:12,519 --> 00:39:16,039
then my real pick that wasn't stolen is animal crossing,

559
00:39:16,239 --> 00:39:19,360
because you know, during a pandemic, what else do we

560
00:39:19,440 --> 00:39:22,480
need them to go off to a deserted island and

561
00:39:22,599 --> 00:39:25,239
have some fun. So I dove into that a little

562
00:39:25,280 --> 00:39:27,599
bit over a week ago and my wife and I

563
00:39:27,679 --> 00:39:30,559
got sucked into it, and I don't know what the

564
00:39:30,599 --> 00:39:33,039
outside world is anymore. So I'm glad to see you all.

565
00:39:34,679 --> 00:39:35,000
Speaker 4: Nice.

566
00:39:35,159 --> 00:39:38,280
Speaker 3: Thanks you, and this hey from the button for the mic.

567
00:39:38,599 --> 00:39:43,400
So yeah, I have one pick and it's Angler related surprise.

568
00:39:43,760 --> 00:39:47,559
So it's a library by that Michael Lake have been

569
00:39:47,599 --> 00:39:51,400
working on a lot. So Michael Lake works a lot

570
00:39:51,480 --> 00:39:56,360
on Angler and rchas content and things like that, and

571
00:39:56,679 --> 00:40:01,719
he built this library called rix Angler, which is based

572
00:40:01,760 --> 00:40:07,360
on another library built called erxjs state, which tries to

573
00:40:07,400 --> 00:40:10,800
fix an issue which is, you know, either you end

574
00:40:10,880 --> 00:40:16,320
up putting everything in your NGRX or your application global states,

575
00:40:16,679 --> 00:40:20,960
or either you handle your stuff in your components and

576
00:40:21,119 --> 00:40:23,840
you end up with lots of subscriptions and then having

577
00:40:23,880 --> 00:40:26,639
to use other libraries to handle those subscriptions. And the

578
00:40:26,719 --> 00:40:30,920
idea of our angular state is there are lots of

579
00:40:30,960 --> 00:40:32,960
ideas in it, but one of the ideas is like

580
00:40:33,000 --> 00:40:36,880
to have a local component state without having to subscribe

581
00:40:36,920 --> 00:40:40,440
manually to it, so you got lots of all observables

582
00:40:40,480 --> 00:40:42,440
and you connect it to your inputs, You connect it

583
00:40:42,480 --> 00:40:45,000
to lots of things in your components and to the

584
00:40:45,039 --> 00:40:48,000
life cycles, and you don't have to care about these things.

585
00:40:48,280 --> 00:40:54,280
And it helps you write reactive stuff without having to

586
00:40:54,320 --> 00:40:59,039
put all your logic JRX, which is not something you

587
00:40:59,079 --> 00:41:03,320
want to do all the time. That's it, very serious things. Funny,

588
00:41:03,480 --> 00:41:04,000
Sorry for that.

589
00:41:06,000 --> 00:41:09,199
Speaker 2: Nice, Thank you, Thank you for the unfunny pick.

590
00:41:09,559 --> 00:41:11,559
Speaker 3: Uns. That's my job.

591
00:41:11,599 --> 00:41:17,480
Speaker 10: That's yeah, now, but that's actually great that Michael is

592
00:41:17,519 --> 00:41:21,679
doing great work around trying to simplify state management.

593
00:41:22,239 --> 00:41:26,039
Speaker 4: So that's a great pick. Okay, so Brooks.

594
00:41:26,559 --> 00:41:30,679
Speaker 8: Yeah, so my pick is loop back for It's a

595
00:41:30,920 --> 00:41:36,199
no JS typescript framework for building you know API. I

596
00:41:36,239 --> 00:41:39,400
got into a recently client had a project with it,

597
00:41:39,519 --> 00:41:42,320
and I had never heard of it before. It's actually

598
00:41:42,320 --> 00:41:45,480
made by IBM. It's open source and it has a

599
00:41:45,559 --> 00:41:49,119
really powerful CLI, which is like the coolest part of it.

600
00:41:49,199 --> 00:41:51,480
You kind of answer questions and all of a sudden

601
00:41:51,920 --> 00:41:55,599
your endpoints are made and working. So it's very cool.

602
00:41:56,079 --> 00:41:56,400
Speaker 4: Nice.

603
00:41:56,639 --> 00:42:03,360
Speaker 2: It's an alternative to the popular nest right, yeah, exactly, Yeah,

604
00:42:03,880 --> 00:42:10,559
awesome great pick. Okay, so my pick is a shameless plug. First,

605
00:42:10,639 --> 00:42:15,679
testangular dot com. We're going to launch another workshop testing workshop,

606
00:42:15,840 --> 00:42:19,360
free testing workshop, So if you go to testangular dot

607
00:42:19,360 --> 00:42:20,280
com and sign.

608
00:42:20,119 --> 00:42:22,000
Speaker 4: Up, should be up this month.

609
00:42:22,599 --> 00:42:26,639
Speaker 2: It was supposed to be an April but Corona and

610
00:42:26,880 --> 00:42:29,280
my other pick is Angie Coon.

611
00:42:29,519 --> 00:42:34,440
Speaker 5: So ngiconf released their videos which I had the pleasure

612
00:42:34,559 --> 00:42:37,199
to be a part of. So you could go to

613
00:42:37,280 --> 00:42:42,360
angconf dot com dot org and register for free and

614
00:42:42,559 --> 00:42:46,119
you can see the lectures. So that's my second pick.

615
00:42:46,199 --> 00:42:48,960
And now for the guest of honor, Yille, what are

616
00:42:49,000 --> 00:42:49,800
your picks?

617
00:42:50,199 --> 00:42:53,760
Speaker 4: I have two picks. One is related to a friend,

618
00:42:53,920 --> 00:42:58,159
the mutual friend of us, wish A Kain. We started

619
00:42:58,199 --> 00:43:03,400
the new venture. He calls it walk We. That application

620
00:43:04,559 --> 00:43:09,320
helps to create our the Winno. It's our our window

621
00:43:09,480 --> 00:43:13,079
playground in the web and it's looking for people who

622
00:43:13,119 --> 00:43:16,880
will help create more components, our the window components, but

623
00:43:17,480 --> 00:43:21,000
in the web environment like you will have to create

624
00:43:21,039 --> 00:43:25,639
those elements using gleat dash element if you know that library.

625
00:43:26,079 --> 00:43:30,920
So one it's Risha Kid's walk We and the second

626
00:43:31,000 --> 00:43:37,000
one is not related to anything but to today. We're

627
00:43:37,039 --> 00:43:42,880
recording and today is the fourth of May and it's

628
00:43:43,000 --> 00:43:49,079
Star Wars Day, and today I'm very fun of Star

629
00:43:49,119 --> 00:43:52,920
Wars things, and one of the things that I'm looking

630
00:43:53,000 --> 00:43:57,599
forward is to see the last episode of the Star Wars.

631
00:43:57,679 --> 00:44:02,679
The Clone World War was animated series that will be

632
00:44:03,519 --> 00:44:06,840
shipped today, So today there is the last episode of

633
00:44:06,920 --> 00:44:10,719
that series, so I'm looking forward for tonight to see

634
00:44:10,760 --> 00:44:12,840
it later on awesome.

635
00:44:13,480 --> 00:44:17,199
Speaker 2: Thank you very much Gil for sharing with us all

636
00:44:17,239 --> 00:44:21,199
the wonderful tricks and tapes a while profiling. Thank you

637
00:44:21,239 --> 00:44:25,360
all all the panelists for joining today, and we'll see

638
00:44:25,360 --> 00:44:29,679
you next time on another great episode of Adventures in Angela.

639
00:44:30,199 --> 00:44:33,320
Speaker 4: Bye bye, thank you everybody. Beys everyone,