1
00:00:00,000 --> 00:00:03,600
Confirm dance, are what I call a
representation of a piece of sub

2
00:00:03,600 --> 00:00:05,900
domain and we should 
differentiate them from 

3
00:00:05,900 --> 00:00:08,900
components because components 
are solving technical problems. 

4
00:00:09,200 --> 00:00:11,700
So, I want to reduce this 
specific functionality it in 

5
00:00:11,700 --> 00:00:15,700
multiple places of my code base,
but Mike from Texas that you're 

6
00:00:15,700 --> 00:00:19,700
looking from that product side, 
you start to look at how you can

7
00:00:19,700 --> 00:00:23,400
create value can generate value 
in isolation for your users. 

8
00:00:28,000 --> 00:00:31,300
Hey everyone. 
My name is Henry Surya Barragan.

9
00:00:32,900 --> 00:00:36,800
And you're listening to the 
tekhelet Juno, the show will be 

10
00:00:36,800 --> 00:00:40,100
bringing you the greatest 
technical leaders practitioners 

11
00:00:40,300 --> 00:00:43,600
and thought leaders in the 
industry to discuss about their 

12
00:00:43,600 --> 00:00:48,400
Journey ideas and practices that
we all can learn and apply to 

13
00:00:48,400 --> 00:00:51,400
build a highly performing 
technical team and to make an 

14
00:00:51,400 --> 00:00:56,100
impact in your personal work. 
So let's dive into our Journal. 

15
00:01:01,100 --> 00:01:02,400
Hello. 
This is Henry. 

16
00:01:02,600 --> 00:01:05,400
It's great to be back here again
with another new episode of the 

17
00:01:05,400 --> 00:01:08,200
tekhelet journal podcast. 
Thanks for spending your time 

18
00:01:08,200 --> 00:01:10,300
with me today, listening to this
episode. 

19
00:01:10,600 --> 00:01:12,400
If you haven't, please subscribe
to Tech. 

20
00:01:12,400 --> 00:01:15,600
Did you know on your favorite 
podcast apps and also follow our

21
00:01:15,600 --> 00:01:19,100
social media channels on 
LinkedIn, Twitter and Instagram,

22
00:01:19,300 --> 00:01:21,700
you can also make some 
contribution to the show and 

23
00:01:21,700 --> 00:01:25,000
support the creation of this 
podcast by subscribing, as a 

24
00:01:25,000 --> 00:01:29,200
patron at technology. 
No, dot f / Patron, and help me 

25
00:01:29,200 --> 00:01:31,900
to continue producing. 
Great content every week. 

26
00:01:32,700 --> 00:01:35,200
For today's episode. 
I am happy to share my 

27
00:01:35,200 --> 00:01:39,300
conversation with Luca Meza. 
Lira, Luca is a principal 

28
00:01:39,300 --> 00:01:43,100
architect at AWS an expert on 
micro front ends. 

29
00:01:43,400 --> 00:01:47,200
And the author of the upcoming 
building micro front-ends book. 

30
00:01:47,700 --> 00:01:51,700
Today's applications have become
increasingly complex and often 

31
00:01:51,700 --> 00:01:55,000
built by a combination of 
multiple teams working together 

32
00:01:55,200 --> 00:01:57,600
in order to deliver. 
The best user experience for 

33
00:01:57,600 --> 00:02:00,800
customers. 
While microservices has become a

34
00:02:00,800 --> 00:02:04,500
popular architecture of choice. 
At the back end Services micro 

35
00:02:04,500 --> 00:02:08,000
front ends also has started to 
offer similar benefits that can 

36
00:02:08,000 --> 00:02:11,700
be applied when building complex
front ends or web applications 

37
00:02:12,400 --> 00:02:15,600
in this episode. 
Luca describe the concept of 

38
00:02:15,600 --> 00:02:19,100
microfinance in depth, along 
with the where and when 

39
00:02:19,100 --> 00:02:22,200
companies should apply this 
concept for building the front 

40
00:02:22,200 --> 00:02:25,600
ends, as well as sharing how he 
successfully implemented 

41
00:02:25,600 --> 00:02:29,000
microfinance at the Zone. 
He also shared about the 

42
00:02:29,000 --> 00:02:33,200
important principles behind 
microfinance why it Is important

43
00:02:33,200 --> 00:02:36,300
to be technology agnostic. 
When building your microphone 

44
00:02:36,300 --> 00:02:40,400
ants and how to design the CI CD
pipelines to stitch the 

45
00:02:40,400 --> 00:02:43,600
different microphone ends 
together and deliver it as a one

46
00:02:43,600 --> 00:02:47,100
unified product. 
Luca also mentioned some of the 

47
00:02:47,100 --> 00:02:50,500
common pitfalls and anti 
patterns that we should avoid 

48
00:02:50,500 --> 00:02:54,300
when using microphones as well 
as sharing his tips on how 

49
00:02:54,300 --> 00:02:57,800
organizations can start adopting
microfinance in their 

50
00:02:57,800 --> 00:03:00,900
architecture. 
I enjoyed learning micro front 

51
00:03:00,900 --> 00:03:04,400
ends from Luca and I hope you 
will enjoy this episode as well.

52
00:03:04,800 --> 00:03:08,000
Consider helping the show by 
living it a rating review or 

53
00:03:08,000 --> 00:03:11,700
comment on your podcast app or 
leave us some comments on our 

54
00:03:11,700 --> 00:03:15,200
social media channels, those 
reviews and comments are one of 

55
00:03:15,200 --> 00:03:18,400
the best ways to help me get 
this podcast to reach more 

56
00:03:18,400 --> 00:03:21,700
listeners and hopefully they can
also benefit from all the 

57
00:03:21,708 --> 00:03:25,000
contents in this podcast. 
So let's get this episode 

58
00:03:25,000 --> 00:03:27,700
started right after our sponsor 
message. 

59
00:03:27,900 --> 00:03:31,000
Are you looking for a new? 
Swag tackle, it Journal. 

60
00:03:31,000 --> 00:03:34,100
Now offers you some swags that 
you can purchase online. 

61
00:03:34,500 --> 00:03:38,400
These wax are printed on demand 
based on your preference and 

62
00:03:38,400 --> 00:03:41,200
will be delivered safely to you 
all over the world where 

63
00:03:41,200 --> 00:03:44,300
shipping is available. 
Check out all the cool tracks 

64
00:03:44,300 --> 00:03:47,200
available by visiting 
technology, you know, dot, f / 

65
00:03:47,200 --> 00:03:49,500
shop, and don't forget to break 
yourself. 

66
00:03:49,600 --> 00:03:51,700
Once you receive any of those 
tracks. 

67
00:03:54,400 --> 00:03:56,700
Hey everyone, welcome back to 
another new episode of the tech 

68
00:03:56,700 --> 00:03:59,100
lead, you know, today. 
I have another awesome guess. 

69
00:03:59,200 --> 00:04:02,100
As for us to have a 
conversation, his name is Luca 

70
00:04:02,100 --> 00:04:04,600
Meza. 
Lira is actually an expert in 

71
00:04:04,600 --> 00:04:07,600
micro front ends. 
So for some of you who are into 

72
00:04:07,600 --> 00:04:10,600
building ui/ux front and 
Technologies, but this is an 

73
00:04:10,600 --> 00:04:11,900
episode that you don't want to 
miss. 

74
00:04:12,300 --> 00:04:14,600
Luca is very expert in 
microphone. 

75
00:04:14,600 --> 00:04:17,899
And since I think long time ago,
maybe let's clarify later with 

76
00:04:17,899 --> 00:04:20,200
him. 
He's been working at dazzling, 

77
00:04:20,300 --> 00:04:23,900
helping them to transform their 
platform into a global streaming

78
00:04:23,900 --> 00:04:26,400
platform. 
And now he's working at AWS 

79
00:04:26,400 --> 00:04:29,000
Amazon web services as principal
architect. 

80
00:04:29,300 --> 00:04:32,400
Welcome to car to the show. 
Good to have you here and hope 

81
00:04:32,400 --> 00:04:34,800
to have a great conversation 
about microfinance. 

82
00:04:35,300 --> 00:04:37,100
Hey harry, thank you for having 
me. 

83
00:04:37,100 --> 00:04:40,500
It's a pleasure being here and 
I'm very excited to have this 

84
00:04:40,500 --> 00:04:42,100
episode video. 
So do come. 

85
00:04:42,100 --> 00:04:44,100
Maybe in the beginning. 
Can you help to introduce 

86
00:04:44,100 --> 00:04:45,800
yourself? 
Maybe telling us about your 

87
00:04:45,800 --> 00:04:47,600
highlights or turning points in 
your career? 

88
00:04:48,600 --> 00:04:52,300
Yeah, absolutely. 
So I started working in it when 

89
00:04:52,300 --> 00:04:55,400
I was 21. 
I must have thought person. 

90
00:04:55,400 --> 00:05:00,100
So no University and I'm 
studying I learn Old school way.

91
00:05:00,100 --> 00:05:03,600
So coding every night every day,
Sunday Saturdays. 

92
00:05:03,700 --> 00:05:05,300
There wasn't a time where I 
stopped. 

93
00:05:05,500 --> 00:05:09,300
I started with flash platform 
back in the days in 2004. 

94
00:05:09,600 --> 00:05:13,000
And there, I hit a lot of 
success, to be honest, because 

95
00:05:13,000 --> 00:05:16,500
the platform was great and allow
me to unleash my creativity. 

96
00:05:16,700 --> 00:05:19,200
I work mainly outside the 
browser. 

97
00:05:19,400 --> 00:05:22,100
So mobile devices, embedded 
devices. 

98
00:05:22,300 --> 00:05:26,100
I work even on a motorbike with 
the creating, like a dashboard 

99
00:05:26,100 --> 00:05:28,300
and digital dashboard instead of
the mechanical one. 

100
00:05:28,400 --> 00:05:31,300
And it was quite And to be 
honest, but after 10 years 

101
00:05:31,300 --> 00:05:34,200
living in Italy, where I'm 
coming from, I decided to move 

102
00:05:34,200 --> 00:05:36,600
to UK. 
First of all, as a lead 

103
00:05:36,600 --> 00:05:39,400
developer in a startup called we
describe. 

104
00:05:39,600 --> 00:05:42,600
And basically we were doing a 
software for creating these kind

105
00:05:42,600 --> 00:05:45,800
of videos where you have like 
hand that is writing and 

106
00:05:45,800 --> 00:05:49,000
mimicking, real person, that is 
throwing after few months. 

107
00:05:49,000 --> 00:05:52,900
I was cold in London and they 
moved as a senior developer in a

108
00:05:52,900 --> 00:05:54,900
gambling company. 
After a few months. 

109
00:05:54,900 --> 00:05:57,900
I became Tech leader, there. 
I change the way how they've 

110
00:05:57,900 --> 00:06:00,200
used to work. 
We Being software because we 

111
00:06:00,200 --> 00:06:03,100
were used to develop gambling 
game, one every nine months. 

112
00:06:03,300 --> 00:06:06,700
And when I left we moved from 
nine to three months of delivery

113
00:06:06,700 --> 00:06:09,600
time where hundreds of people in
my department we were doing 80 

114
00:06:09,600 --> 00:06:12,500
percent of the revenue. 
It was quite fun and very 

115
00:06:12,500 --> 00:06:14,900
engaging. 
I was quite an interesting 

116
00:06:14,900 --> 00:06:17,500
project for me because it wasn't
touching only the tech part. 

117
00:06:17,500 --> 00:06:22,900
But also the people side after 
that I moved to an agency called

118
00:06:22,900 --> 00:06:25,800
massive interactive. 
That was specialized on 

119
00:06:25,800 --> 00:06:28,500
multi-platform core streaming 
platform. 

120
00:06:28,800 --> 00:06:31,300
I became Extremely passionate 
about that because I understood 

121
00:06:31,300 --> 00:06:34,200
that the industry was in the 
middle of a revolution. 

122
00:06:34,300 --> 00:06:36,800
And it was extremely 
interesting, developing on 

123
00:06:36,900 --> 00:06:40,600
consoles, Smart TVs and set-top.
Boxes had the opportunity to 

124
00:06:40,600 --> 00:06:44,100
have my hands dirty in the code 
for a few set of boxes. 

125
00:06:44,100 --> 00:06:47,000
It was extremely challenging but
I have to say extremely 

126
00:06:47,000 --> 00:06:48,900
rewarding as well. 
They are. 

127
00:06:48,900 --> 00:06:52,500
I follow a project for a company
called The Zone, where then a 

128
00:06:52,500 --> 00:06:56,000
transition to them. 
Basically, in 60 year, we move 

129
00:06:56,000 --> 00:06:59,000
from not having a brand and not 
having a reputation. 

130
00:06:59,100 --> 00:07:01,900
Into having a global 
distribution in over 200 

131
00:07:01,900 --> 00:07:05,900
countries and the think that was
one of the key highlight of my 

132
00:07:05,900 --> 00:07:08,800
career because I had the 
possibility to take the project 

133
00:07:08,800 --> 00:07:11,700
basically day one. 
Since the Inception work closely

134
00:07:11,700 --> 00:07:14,700
with the product team and create
a platform that raised a lot of 

135
00:07:14,700 --> 00:07:17,400
success worldwide. 
I was able to travel a lot, the 

136
00:07:17,400 --> 00:07:19,900
word. 
I was in Japanese launch. 

137
00:07:20,000 --> 00:07:23,200
I wasn't Italian launch. 
I follow basically all the key 

138
00:07:23,200 --> 00:07:26,400
turning point of the company and
I was slowly but steadily 

139
00:07:26,400 --> 00:07:30,300
growing personally and also my 
career wise Because I became at 

140
00:07:30,300 --> 00:07:32,300
the end, vice president of 
architecture there. 

141
00:07:32,600 --> 00:07:36,000
And then after six years, I 
thought that was the time to see

142
00:07:36,000 --> 00:07:38,600
if this knowledge could be 
helpful for other companies. 

143
00:07:38,600 --> 00:07:41,100
So then I moved to a WSS 
principal architect. 

144
00:07:41,800 --> 00:07:45,800
So, look at what made you decide
to go into microfinance because 

145
00:07:45,800 --> 00:07:47,800
hearing what you say. 
Just now about your career, it 

146
00:07:47,800 --> 00:07:50,500
seems like a lot of variety 
things that you did. 

147
00:07:50,600 --> 00:07:54,200
There is an early sign for you 
working in my digital dashboard 

148
00:07:54,200 --> 00:07:55,700
and things like that. 
But you moved on into 

149
00:07:55,700 --> 00:07:58,500
architecture Global streaming 
platforms and things like that. 

150
00:07:58,800 --> 00:08:00,900
What me? 
Decide to go into microfinance. 

151
00:08:01,400 --> 00:08:04,900
Yeah, that's a good question. 
So, back in the days, almost 

152
00:08:04,900 --> 00:08:07,100
five years ago. 
We had the challenge. 

153
00:08:07,100 --> 00:08:09,900
We just released the Zone 
platform in few countries. 

154
00:08:10,000 --> 00:08:12,000
Germany, Austria Switzerland, in
Japan. 

155
00:08:12,200 --> 00:08:15,200
We had a massive growth. 
We move from hundreds to 

156
00:08:15,200 --> 00:08:17,900
thousands of people in a year 
and a half more or less. 

157
00:08:18,300 --> 00:08:23,100
Obviously, we wanted to develop 
our solution and have certain 

158
00:08:23,100 --> 00:08:26,900
flexibility and agility mean. 
Well, we were developing and the

159
00:08:26,900 --> 00:08:29,000
team was distributed across 
Europe. 

160
00:08:29,200 --> 00:08:34,799
So one challenge that I had to 
face was thinking how to move 

161
00:08:34,799 --> 00:08:38,299
from a monolithic code base on 
the front-end and back-end to a 

162
00:08:38,299 --> 00:08:42,299
distributed system that would 
allow a team to work at their 

163
00:08:42,299 --> 00:08:45,400
own speed and reducing the 
communication of red across 

164
00:08:45,400 --> 00:08:48,100
teams. 
Obviously, on the back end, we 

165
00:08:48,100 --> 00:08:51,700
have Consolidated Partners like,
microservices, but on the front 

166
00:08:51,700 --> 00:08:54,100
end, we didn't have much to be 
honest with you. 

167
00:08:54,400 --> 00:08:58,100
So what I have done, I started 
his journey on identify. 

168
00:08:58,100 --> 00:09:01,900
What are the Rules for making a 
successful distributed system 

169
00:09:01,900 --> 00:09:04,100
architecture. 
And I took the principle of 

170
00:09:04,100 --> 00:09:07,900
microservices and I try slowly 
but steady to apply on the front

171
00:09:07,900 --> 00:09:11,700
end because the reality was I 
couldn't have tens of 

172
00:09:11,700 --> 00:09:16,000
developers, working on the same 
code base and coordinate across 

173
00:09:16,000 --> 00:09:18,700
multiple offices. 
Also, with pandemic that 

174
00:09:18,700 --> 00:09:21,700
situation could be even worse 
because you start to have people

175
00:09:21,700 --> 00:09:25,100
working different time zones. 
So what we have done, basically 

176
00:09:25,100 --> 00:09:28,200
taking those principles behind 
microservices, apply to the 

177
00:09:28,200 --> 00:09:31,400
microphone tents and Came up 
with a bunch of principles that 

178
00:09:31,400 --> 00:09:35,900
were our North Star and start to
slice our application using a 

179
00:09:35,900 --> 00:09:39,300
bit of domain-driven design. 
And looking at how our users, 

180
00:09:39,300 --> 00:09:41,200
we're interacting with the 
platform. 

181
00:09:41,400 --> 00:09:44,700
And based on those information. 
We sit down with the small team 

182
00:09:44,700 --> 00:09:47,000
that we had back in the days. 
Looking at the platform. 

183
00:09:47,000 --> 00:09:50,700
We identify a bunch of bounded 
context, that could be splitted 

184
00:09:50,700 --> 00:09:54,100
the platform and then suddenly 
we realized that it could be 

185
00:09:54,100 --> 00:09:57,400
extended and to end at the front
end but as well on the back end 

186
00:09:57,600 --> 00:09:59,000
that was an extremely 
interesting. 

187
00:09:59,200 --> 00:10:01,000
Journey. 
Because as you can imagine five 

188
00:10:01,000 --> 00:10:04,800
six years ago, they wear and 
guidelines on how to do that for

189
00:10:04,800 --> 00:10:07,100
us. 
We had to reason find the right 

190
00:10:07,100 --> 00:10:09,200
way for approaching this 
challenge. 

191
00:10:09,400 --> 00:10:11,200
It turned out that in less than 
a month. 

192
00:10:11,200 --> 00:10:14,400
We were able to have a POC up 
and running and working on web 

193
00:10:14,400 --> 00:10:17,700
and few TV devices. 
Performances were pretty good. 

194
00:10:17,900 --> 00:10:20,800
Obviously back in the days. 
We had to figure out the right 

195
00:10:20,800 --> 00:10:24,600
way to do this because we could 
end up very easily to have an 

196
00:10:24,600 --> 00:10:27,300
overhead of creating a lot of 
tools for streamline the 

197
00:10:27,300 --> 00:10:30,300
developer experience. 
So, So, one of the Mantra that 

198
00:10:30,300 --> 00:10:35,100
we had is trying to keep our 
implementation as agnostic and 

199
00:10:35,100 --> 00:10:37,000
close to vanilla JavaScript as 
possible. 

200
00:10:37,200 --> 00:10:40,500
That doesn't mean we couldn't 
use Frameworks or anything but 

201
00:10:40,500 --> 00:10:45,500
we were smart enough back in the
days to try to simplify the 

202
00:10:45,500 --> 00:10:48,700
creation of all microphone 10th 
and compose them all together. 

203
00:10:48,700 --> 00:10:53,300
Using paradigms that are already
available like using HTML Dom 

204
00:10:53,400 --> 00:10:55,600
for stitching, everything 
together and leveraging a 

205
00:10:55,700 --> 00:10:59,000
solution like a pending the 
synchronous JavaScript. 

206
00:10:59,400 --> 00:11:01,900
On the dorm and automatically 
the browser was taking care 

207
00:11:01,900 --> 00:11:04,000
about loading and parsing and 
everything. 

208
00:11:04,200 --> 00:11:08,300
So we try to be as simple as 
possible in order to achieve our

209
00:11:08,300 --> 00:11:11,500
goal and split up the 
development of our tips. 

210
00:11:12,100 --> 00:11:15,000
So maybe for people who are 
mostly familiar with 

211
00:11:15,000 --> 00:11:17,700
microservices. 
Could you maybe describe what 

212
00:11:17,700 --> 00:11:20,800
does it mean to have a micro 
front-ends architecture? 

213
00:11:21,300 --> 00:11:23,300
Yeah. 
So usually when you take all 

214
00:11:23,300 --> 00:11:26,600
microservices you start to look 
at your subdomain. 

215
00:11:26,600 --> 00:11:28,900
So you take a complex process 
form and you did. 

216
00:11:29,100 --> 00:11:31,600
Buy them in smaller problems. 
For instance. 

217
00:11:31,600 --> 00:11:34,500
Let's take Netflix that probably
everyone knows you thinking 

218
00:11:34,500 --> 00:11:36,700
Netflix. 
Obviously, you don't just watch 

219
00:11:36,700 --> 00:11:39,400
some content. 
You have like customer support, 

220
00:11:39,600 --> 00:11:42,800
you have a possibility to change
subscription type. 

221
00:11:42,900 --> 00:11:46,200
You can pay with PayPal or 
credit card and all these part 

222
00:11:46,200 --> 00:11:47,700
contributes to the final 
platform. 

223
00:11:47,700 --> 00:11:51,200
So, the final domain, obviously,
you cannot take all that in one 

224
00:11:51,200 --> 00:11:53,400
go. 
You need to start to slice those

225
00:11:53,400 --> 00:11:55,400
boundaries and divide them in 
subdomains. 

226
00:11:55,600 --> 00:11:58,300
And then inside the subdomains 
you have what is called bounded 

227
00:11:58,300 --> 00:12:01,100
context-aware? 
Are you identified some areas 

228
00:12:01,100 --> 00:12:04,400
that can be taken in isolation? 
The same thing happened on the 

229
00:12:04,400 --> 00:12:06,900
front end. 
So if you look at the front and 

230
00:12:06,900 --> 00:12:10,600
side imagine like the Netflix 
website, what do you usually do 

231
00:12:10,600 --> 00:12:13,100
as a new user? 
You go to a landing page, then 

232
00:12:13,100 --> 00:12:17,300
if you like the offering, you go
to the signup journey and that 

233
00:12:17,300 --> 00:12:19,900
during the signup flow, when you
finish that, you go to the 

234
00:12:19,900 --> 00:12:21,800
catalog and you start to watch 
content. 

235
00:12:21,900 --> 00:12:25,600
So just with this free, you can 
easily identify potentially free

236
00:12:25,600 --> 00:12:28,900
different user flows. 
The first one is for the users. 

237
00:12:29,100 --> 00:12:31,700
That are going to Netflix and 
trying to understand what the 

238
00:12:31,700 --> 00:12:33,900
service is. 
And maybe they stopped there and

239
00:12:33,900 --> 00:12:36,600
maybe they don't care because 
it's not fulfilling what they 

240
00:12:36,600 --> 00:12:38,500
are looking for. 
And therefore they stopped. 

241
00:12:38,500 --> 00:12:43,100
Their second step is signing up.
Usually you have one part for 

242
00:12:43,100 --> 00:12:46,500
your personal data and you share
your email address, first name, 

243
00:12:46,500 --> 00:12:48,600
and last name. 
And then the second part for 

244
00:12:48,600 --> 00:12:50,500
your subscription type and 
payment. 

245
00:12:50,700 --> 00:12:54,600
So those things for instance can
be bundled together because if 

246
00:12:54,600 --> 00:12:58,100
I'm a user, what I'm doing is 
first understanding, if I like 

247
00:12:58,100 --> 00:13:00,500
the offering if I go The 
offering and move forward. 

248
00:13:00,600 --> 00:13:03,700
But when I have done this and 
I'm convinced about subscribing,

249
00:13:03,700 --> 00:13:06,900
I'm not indicated User. 
It's unlikely that I'm going to 

250
00:13:06,900 --> 00:13:09,000
the landing page or to the sign 
up page. 

251
00:13:09,200 --> 00:13:13,400
The reasoning behind that is try
to create some context and some 

252
00:13:13,400 --> 00:13:15,800
experiences. 
If you want for the users, that 

253
00:13:15,800 --> 00:13:20,300
will allow the user to download 
the code only for that specific 

254
00:13:20,300 --> 00:13:22,000
experience. 
Obviously, if you want to 

255
00:13:22,000 --> 00:13:24,000
download more happy days, you 
can do that. 

256
00:13:24,100 --> 00:13:27,000
But that's the initial idea 
obviously later on. 

257
00:13:27,000 --> 00:13:28,900
We discover that you can even go
more. 

258
00:13:29,100 --> 00:13:31,500
Granular, so, there are 
situations where for large 

259
00:13:31,500 --> 00:13:34,100
organization, especially, you 
start to have microphone 

260
00:13:34,100 --> 00:13:37,600
tensing, the same view, because 
in reality, there are situations

261
00:13:37,600 --> 00:13:40,100
where you have multiple tips, or
you have a microphone that can 

262
00:13:40,100 --> 00:13:42,300
be reusable across multiple 
views. 

263
00:13:42,600 --> 00:13:46,900
So, in both cases, having my 
contents that are smaller fine 

264
00:13:46,900 --> 00:13:49,300
grain compared to a more larger 
drain. 

265
00:13:49,300 --> 00:13:51,700
It solution is definitely a 
possibility. 

266
00:13:51,900 --> 00:13:54,600
So at the end of microphone 
tents are what I call a 

267
00:13:54,600 --> 00:13:57,300
representation of a piece of sub
domain and we should 

268
00:13:57,300 --> 00:13:58,900
differentiate them from 
component. 

269
00:13:59,100 --> 00:14:01,400
Those components are solving 
technical problems. 

270
00:14:01,700 --> 00:14:04,200
So I want to reduce this 
specific functionality it in 

271
00:14:04,200 --> 00:14:07,900
multiple places of my code base.
But Mike from that, is that the,

272
00:14:07,900 --> 00:14:11,800
you're looking from that product
side, you start to look at how 

273
00:14:11,800 --> 00:14:15,300
you can create value can 
generate value in isolation for 

274
00:14:15,300 --> 00:14:17,300
your users. 
And that's basically where we 

275
00:14:17,300 --> 00:14:18,800
stand at the moment. 
We make them tense. 

276
00:14:19,400 --> 00:14:22,500
So in terms of applicability to 
technology, is it only for 

277
00:14:22,500 --> 00:14:23,900
web-based? 
Front-end. 

278
00:14:24,100 --> 00:14:26,200
Can you also apply to mobile 
devices? 

279
00:14:26,200 --> 00:14:28,900
Native hybrid? 
Yeah, so, it's Anarchy. 

280
00:14:29,000 --> 00:14:31,100
Textured. 
So therefore is not bounded to a

281
00:14:31,108 --> 00:14:34,200
specific technology. 
We applied on web and TV 

282
00:14:34,200 --> 00:14:36,100
devices. 
Not all of them, but some of 

283
00:14:36,100 --> 00:14:39,300
them therefore living room 
devices and the outcome was 

284
00:14:39,300 --> 00:14:42,300
positive or mobile. 
We didn't because we were 

285
00:14:42,300 --> 00:14:45,500
working with Native Technologies
and the back in the days. 

286
00:14:45,500 --> 00:14:48,700
We didn't spend too much time on
revamping that because 

287
00:14:48,700 --> 00:14:50,700
application was running very 
well before. 

288
00:14:50,700 --> 00:14:52,800
We didn't need to review that 
part. 

289
00:14:52,800 --> 00:14:54,700
I would say yes, is applicable, 
so mobile. 

290
00:14:54,700 --> 00:14:57,700
So if you're using react native 
or other solution, yes, you can 

291
00:14:57,700 --> 00:15:00,800
definitely think about this. 
The only challenge that you have

292
00:15:00,800 --> 00:15:02,400
a mobile. 
That's a question. 

293
00:15:02,400 --> 00:15:05,200
I had with quite a few people. 
Is that the nature of web 

294
00:15:05,200 --> 00:15:07,600
usually is that you are online 
by Design? 

295
00:15:07,600 --> 00:15:10,000
So, if you want to Consumer 
websites, you need to be online 

296
00:15:10,200 --> 00:15:12,600
on mobile. 
You need to think also on the 

297
00:15:12,600 --> 00:15:15,700
offline experience. 
So, if you start with an empty 

298
00:15:15,700 --> 00:15:18,500
package, if you want, and you 
have an empty application as the

299
00:15:18,500 --> 00:15:20,800
device that you are composing, 
everything that could be an 

300
00:15:20,800 --> 00:15:23,000
idea. 
But if you think about creating 

301
00:15:23,000 --> 00:15:26,000
a smooth user experience, 
potentially, you need also to 

302
00:15:26,000 --> 00:15:29,400
think on downloading these 
microphones and During inside 

303
00:15:29,400 --> 00:15:33,700
the device or maybe having just 
a bare minimum set that will 

304
00:15:33,700 --> 00:15:36,700
allow the user to have a decent 
offline experience. 

305
00:15:36,700 --> 00:15:39,100
And then you have let's say 
something more to think about. 

306
00:15:39,100 --> 00:15:42,200
I think it's totally doable. 
But at the same time you have 

307
00:15:42,200 --> 00:15:44,600
more to think about because 
obviously the nature of the 

308
00:15:44,600 --> 00:15:48,400
experience there is offline and 
online and sometimes offline. 

309
00:15:48,400 --> 00:15:50,800
First personally. 
I'm quite annoying when I play 

310
00:15:50,800 --> 00:15:53,200
games that you can only play 
online because maybe you are 

311
00:15:53,200 --> 00:15:56,500
doing commute and you are in the
tubule in London and you don't 

312
00:15:56,500 --> 00:15:58,100
have connection for any given 
reason. 

313
00:15:58,100 --> 00:16:00,800
Therefore, I To play My 
Favourite game by a cannot. 

314
00:16:01,000 --> 00:16:03,400
So we need to think also about 
this stuff. 

315
00:16:03,400 --> 00:16:07,300
It's not just showing a nice 
page say, oh, please connect to 

316
00:16:07,300 --> 00:16:08,900
the internet because sometimes 
you can. 

317
00:16:09,500 --> 00:16:12,400
So if I hear about the history, 
just now when you mentioned the 

318
00:16:12,400 --> 00:16:14,700
work that you did with 
microphone and you are actually 

319
00:16:14,700 --> 00:16:18,000
taking some of the principles 
from the micro Services, which 

320
00:16:18,000 --> 00:16:20,700
has been around for longer than 
microfinance. 

321
00:16:21,000 --> 00:16:24,000
So, now that you have this both 
microservice and micro 

322
00:16:24,000 --> 00:16:27,000
front-ends, how does it work? 
Do they actually vertically 

323
00:16:27,000 --> 00:16:30,600
share the same team. 
Same, Groups or they also still 

324
00:16:30,600 --> 00:16:32,100
split between front-end and 
back-end. 

325
00:16:32,700 --> 00:16:34,900
So there are different schools 
of thought. 

326
00:16:34,900 --> 00:16:36,800
I personally think you can do 
both. 

327
00:16:36,800 --> 00:16:41,100
And I explain why one way to 
endl to the team Communications.

328
00:16:41,100 --> 00:16:43,000
Usually it's through API 
contract. 

329
00:16:43,200 --> 00:16:47,900
Apis basically allows you to 
define a contract between two or

330
00:16:47,900 --> 00:16:51,500
multiple parties, as long as you
respect the contract, everyone 

331
00:16:51,500 --> 00:16:54,000
can work in isolation and can 
work in parallel. 

332
00:16:54,300 --> 00:16:58,400
So therefore in our case that we
had multiple devices mobile 

333
00:16:58,400 --> 00:16:59,400
weapon. 
Room. 

334
00:16:59,400 --> 00:17:02,500
We decided to have teams that 
were working on your front end 

335
00:17:02,500 --> 00:17:05,599
and only or back in. 
Because otherwise if you think 

336
00:17:05,599 --> 00:17:09,599
about cross-functional teams, we
ended up with 15 people just on 

337
00:17:09,599 --> 00:17:12,400
development side, without taking
care about qas and everything. 

338
00:17:12,400 --> 00:17:15,000
Because the variety of languages
and everything that we were 

339
00:17:15,099 --> 00:17:18,300
working on, wouldn't allow us to
have a smaller team. 

340
00:17:18,500 --> 00:17:23,200
So if study, if we divided this 
by domain by Target, this could 

341
00:17:23,200 --> 00:17:25,599
help us to achieve what we want 
to do. 

342
00:17:25,800 --> 00:17:28,900
The way, how we take all that 
without having a first class. 

343
00:17:29,000 --> 00:17:31,900
A citizen in one of the photon 
because potentially we could 

344
00:17:31,900 --> 00:17:35,000
say, we have the back end 
developers together with the web

345
00:17:35,000 --> 00:17:37,400
developers and we can create a 
cross-functional team. 

346
00:17:37,600 --> 00:17:40,800
But in reality, web became the 
first class citizen because all 

347
00:17:40,800 --> 00:17:43,100
the apis would be designed adopt
for that. 

348
00:17:43,100 --> 00:17:46,000
But in reality, we want to have 
a fair way to handle a 

349
00:17:46,000 --> 00:17:49,300
cross-platform application. 
So you can work in both ways and

350
00:17:49,300 --> 00:17:52,600
I think apis are the key using 
techniques like back-end for 

351
00:17:52,600 --> 00:17:56,700
front-end, or using graphql 
would allow you to decouple the 

352
00:17:56,700 --> 00:17:59,300
to team. 
So if you are working with Once 

353
00:17:59,300 --> 00:18:02,500
team says, they calling a child 
or cross-functional teams. 

354
00:18:02,700 --> 00:18:06,400
Either way, you can work with 
both also have want to extend 

355
00:18:06,400 --> 00:18:08,500
this concept. 
Imagine that, for instance. 

356
00:18:08,500 --> 00:18:11,500
You want to migrate your front 
end to microphone tense. 

357
00:18:11,500 --> 00:18:14,300
But you need to remain with the 
monolithic code base on the back

358
00:18:14,300 --> 00:18:17,300
end, you can do in the same way 
as long as you work with a pi 

359
00:18:17,300 --> 00:18:20,000
controller because at the end of
the day, there is a nice 

360
00:18:20,000 --> 00:18:22,200
separation between front-end and
back-end. 

361
00:18:22,300 --> 00:18:24,500
The apis are creating these 
loose. 

362
00:18:24,500 --> 00:18:27,800
Couple Wars between the truth 
when we start with a very 

363
00:18:27,800 --> 00:18:30,700
tightly coupled words. 
Is where I start to be worried 

364
00:18:30,700 --> 00:18:33,700
because then the evolution of 
either party could be 

365
00:18:33,700 --> 00:18:36,600
compromised, speaking about 
different teams, different 

366
00:18:36,600 --> 00:18:38,900
companies, these days, right? 
They are all in different 

367
00:18:38,900 --> 00:18:40,600
situations. 
Some are still working on 

368
00:18:40,600 --> 00:18:43,600
monolith either back-end and 
front-end, some are using single

369
00:18:43,600 --> 00:18:46,700
page, application back and for 
front-end and different devices,

370
00:18:46,700 --> 00:18:49,200
and all that. 
When should we actually start 

371
00:18:49,200 --> 00:18:53,300
thinking about microfinance is 
that turning point in a 

372
00:18:53,400 --> 00:18:56,100
particular situation within the 
team or maybe challenges in 

373
00:18:56,100 --> 00:18:58,800
terms of traffic or situational 
about the company? 

374
00:18:59,200 --> 00:19:01,400
That we should stop thinking 
about micro front ends. 

375
00:19:02,100 --> 00:19:02,900
Yeah. 
Absolutely. 

376
00:19:03,000 --> 00:19:06,100
Let's start answering with one 
thing that I truly believe 

377
00:19:06,100 --> 00:19:08,100
microphone tanks are not a 
silver bullet. 

378
00:19:08,400 --> 00:19:10,700
I'm not here advocating that we 
should do by great. 

379
00:19:10,700 --> 00:19:13,700
Every workload make from tense 
because that's definitely is not

380
00:19:13,700 --> 00:19:17,000
suitable for many companies. 
I think there are some turning 

381
00:19:17,000 --> 00:19:20,300
points where, for instance, you 
have large organizations with 

382
00:19:20,300 --> 00:19:22,500
many teams that are working on 
the same code base. 

383
00:19:22,700 --> 00:19:25,600
And you want to create 
independent teams that could 

384
00:19:25,600 --> 00:19:28,800
work at their own piece. 
That is definitely the best case

385
00:19:28,800 --> 00:19:31,400
for or microphone tense. 
Another situation that I have 

386
00:19:31,400 --> 00:19:34,700
seen microphone tense working. 
Well, he's with multi-tier 

387
00:19:34,700 --> 00:19:38,200
applications where for instance,
you are offering as a service 

388
00:19:38,200 --> 00:19:41,900
and you want to have multiple 
modules, you create similar 

389
00:19:41,900 --> 00:19:45,100
infrastructure for all your 
customers, but at the end, you 

390
00:19:45,100 --> 00:19:47,000
always have a part that you need
to modularize. 

391
00:19:47,000 --> 00:19:49,900
So therefore you can save it. 
Assume you have time microphone 

392
00:19:49,900 --> 00:19:53,600
tens nine of them remain the 
same and one can be customizable

393
00:19:53,600 --> 00:19:56,700
for specific customer. 
That is another thing that I 

394
00:19:56,700 --> 00:20:01,300
have discover alongside this I 
have the fortune to interview 

395
00:20:01,300 --> 00:20:03,800
and speak with people all over 
the world that are embracing 

396
00:20:03,800 --> 00:20:06,600
this technique. 
That's also why I'm spending a 

397
00:20:06,608 --> 00:20:09,100
lot of time advocating that in 
reality. 

398
00:20:09,100 --> 00:20:11,000
To be honest with you. 
I think in architecture, you 

399
00:20:11,000 --> 00:20:14,500
always find trade-offs the 
recent best practices because 

400
00:20:14,500 --> 00:20:17,300
best practices are based on the 
context and if you don't 

401
00:20:17,300 --> 00:20:19,600
understand the context, you 
cannot replicate the best 

402
00:20:19,600 --> 00:20:22,300
practice because it could work 
very well in one company but not

403
00:20:22,300 --> 00:20:24,300
in another. 
Therefore, in my opinion, 

404
00:20:24,400 --> 00:20:27,200
microphone tents are a very 
interesting approach that we 

405
00:20:27,200 --> 00:20:29,200
should work alongside. 
Go page. 

406
00:20:29,200 --> 00:20:33,100
Application Jam stack or server 
side rendering applications 

407
00:20:33,400 --> 00:20:36,200
should be used with coaches 
because obviously is providing. 

408
00:20:36,200 --> 00:20:39,200
Those are some pitfalls. 
You start to create multiple Ci 

409
00:20:39,200 --> 00:20:42,600
City pipelines that you need to 
have a strong observability, a 

410
00:20:42,600 --> 00:20:45,000
strategy behind that. 
So all the things that we have 

411
00:20:45,000 --> 00:20:48,300
seen with micro services are 
also true core microphone times 

412
00:20:48,300 --> 00:20:50,600
because the reality of the 
things is you have similar 

413
00:20:50,600 --> 00:20:52,500
things. 
You have distributed systems 

414
00:20:52,500 --> 00:20:55,700
that have similar problems and 
see their benefits as well. 

415
00:20:55,900 --> 00:20:58,800
Therefore, as long as your 
benefits into your specific. 

416
00:20:59,000 --> 00:21:01,600
Are overcoming. 
The drawbacks definitely is a 

417
00:21:01,608 --> 00:21:04,600
good approach. 
But sometimes I saw people that 

418
00:21:04,600 --> 00:21:08,000
currently are taking this wave 
of my contents and just using it

419
00:21:08,000 --> 00:21:11,200
is more a project and they are 
creating in my opinion, a lot of

420
00:21:11,200 --> 00:21:14,500
overhead for nothing because the
reality, they won't be able to 

421
00:21:14,500 --> 00:21:17,900
leverage the benefits provided 
by microphone tense because 

422
00:21:17,900 --> 00:21:20,800
obviously the small team can 
achieve independence and 

423
00:21:20,800 --> 00:21:23,400
modularity. 
Also, we just good coding 

424
00:21:23,400 --> 00:21:26,200
practices because encapsulation 
and everything that we have 

425
00:21:26,200 --> 00:21:29,700
learned in the past with design 
patterns and Be applicable 

426
00:21:29,700 --> 00:21:32,700
easily also, with two or three 
things working together in the 

427
00:21:32,700 --> 00:21:35,200
same code base. 
My contacts are moving that to 

428
00:21:35,200 --> 00:21:38,100
the next level, especially when 
you have distributed teams, you 

429
00:21:38,100 --> 00:21:41,200
want to reduce communication 
override across teams and you 

430
00:21:41,200 --> 00:21:44,900
want to create independent 
teams, but obviously this has to

431
00:21:44,900 --> 00:21:47,100
be reflected also in the 
organization structure. 

432
00:21:47,200 --> 00:21:49,300
So you the moment if you are 
using micro services and 

433
00:21:49,300 --> 00:21:52,500
microphone 10th, you need also 
to decentralize the decision 

434
00:21:52,500 --> 00:21:56,400
making so the domain expert. 
Now the developers should take 

435
00:21:56,400 --> 00:21:58,800
certain decisions and making 
certain code. 

436
00:21:59,100 --> 00:22:02,000
East Side, certain boundaries, 
and the boundaries, usually are 

437
00:22:02,000 --> 00:22:05,300
defined by that leadership, 
either platform team or 

438
00:22:05,300 --> 00:22:08,000
Architects. 
Principal and so on, instead of 

439
00:22:08,000 --> 00:22:11,500
dictating things, in my opinion,
should enabling the teams to do 

440
00:22:11,500 --> 00:22:14,400
their job properly, and they 
create the boundaries where they

441
00:22:14,400 --> 00:22:16,800
should operate, because they 
have a decent knowledge of the 

442
00:22:16,800 --> 00:22:19,300
big picture. 
Obviously, the other activity 

443
00:22:19,300 --> 00:22:22,500
that those people should do is 
facing patterns that are 

444
00:22:22,500 --> 00:22:24,600
happening inside the team. 
So, for instance, if a specific 

445
00:22:24,600 --> 00:22:27,500
theme is solving a problem and 
that the architect of the tech 

446
00:22:27,500 --> 00:22:31,100
leader, the principal knows that
another team is facing similar 

447
00:22:31,100 --> 00:22:33,100
problems. 
May be taking that pattern 

448
00:22:33,100 --> 00:22:36,500
creating the opportunity for 
sharing and see if they can 

449
00:22:36,500 --> 00:22:40,200
reuse the same approach. 
I definitely could be a new 

450
00:22:40,200 --> 00:22:42,400
activity that this kind of 
people should do because they 

451
00:22:42,400 --> 00:22:45,400
should own the big picture and 
allow the team to make their own

452
00:22:45,400 --> 00:22:47,700
decision. 
Truly believe that the Box model

453
00:22:47,700 --> 00:22:49,400
where you build your own you 
run. 

454
00:22:49,400 --> 00:22:52,200
It is the right way when you 
Embrace distributed systems, 

455
00:22:52,200 --> 00:22:55,500
because otherwise, you create 
external bottlenecks that are 

456
00:22:55,500 --> 00:22:58,700
basically frustrating the team 
and not allowing the company to 

457
00:22:58,700 --> 00:23:00,300
get. 
Main benefits of these 

458
00:23:00,300 --> 00:23:03,100
architectures, you mentioned 
that you have met. 

459
00:23:03,100 --> 00:23:06,200
A lot of people who try to 
implement this microphone stands

460
00:23:06,400 --> 00:23:08,900
apart from dozen who has done it
properly. 

461
00:23:09,100 --> 00:23:12,400
What are some of the maybe 
famous applications or systems 

462
00:23:12,400 --> 00:23:15,200
around the world that I actually
embracing microfinance? 

463
00:23:15,900 --> 00:23:18,400
Yeah. 
Sure a publicly I can tell you 

464
00:23:18,400 --> 00:23:20,800
there are quite a few companies 
that came out with that. 

465
00:23:20,800 --> 00:23:23,700
So Ikea is the first one that 
using Edge side. 

466
00:23:23,700 --> 00:23:28,000
Include Salon do is another one.
That is a fashion e-commerce and

467
00:23:28,000 --> 00:23:29,800
the de to implement. 
Creation of my contents and 

468
00:23:29,800 --> 00:23:31,700
oppressors. 
The first one that Frameworks 

469
00:23:31,700 --> 00:23:35,000
called Taylor JS. 
PayPal recently published quite 

470
00:23:35,000 --> 00:23:38,300
a few post around that so if 
you're a user of people, 

471
00:23:38,400 --> 00:23:40,600
definitely you're using Mac. 
So that's architecture. 

472
00:23:40,800 --> 00:23:44,600
Same for American Express. 
They release an open source 

473
00:23:44,600 --> 00:23:46,800
framework, all across, that is 
doing that. 

474
00:23:47,000 --> 00:23:51,200
Other companies like Skyscanner 
is using them open table to a 

475
00:23:51,200 --> 00:23:54,400
certain extent. 
Also the Amazon Marketplace if 

476
00:23:54,400 --> 00:23:58,700
you see the code, how is divided
inside expecting the website? 

477
00:23:58,900 --> 00:24:01,900
You can see there are some 
approaches similar to microphone

478
00:24:01,900 --> 00:24:04,300
10th. 
Therefore at the moment many 

479
00:24:04,300 --> 00:24:07,300
large organization has 
implemented that but also a 

480
00:24:07,300 --> 00:24:09,400
smaller ones. 
We're looking for 

481
00:24:09,400 --> 00:24:12,100
decentralisation of their 
organization and powering the 

482
00:24:12,100 --> 00:24:16,100
team's because in reality those 
principles that we discussed so 

483
00:24:16,100 --> 00:24:19,600
far are also affecting the 
engineering culture and 

484
00:24:19,600 --> 00:24:22,400
organization structure. 
Usually architecture goes hand 

485
00:24:22,400 --> 00:24:24,700
in hand with that. 
We cannot forget about home with

486
00:24:24,700 --> 00:24:25,900
low. 
Therefore. 

487
00:24:25,900 --> 00:24:29,200
We need to always bear in mind 
that our decisions are And not 

488
00:24:29,200 --> 00:24:32,300
just technical but also 
affecting the organization, the 

489
00:24:32,300 --> 00:24:35,700
communication flow between teens
speaking about principles. 

490
00:24:35,700 --> 00:24:38,100
And you mentioned early in the 
conversation that actually you 

491
00:24:38,100 --> 00:24:40,100
borrow some of the microservice 
principles. 

492
00:24:40,400 --> 00:24:43,100
Maybe for some people who are 
not familiar with micro service 

493
00:24:43,100 --> 00:24:45,700
and best practices. 
What are some of the principles 

494
00:24:45,700 --> 00:24:48,200
that you took from micro 
services that are also good to 

495
00:24:48,200 --> 00:24:50,600
implement in microfinance. 
Yeah. 

496
00:24:50,600 --> 00:24:54,200
So using domain driven design, 
for understanding the bond 

497
00:24:54,200 --> 00:24:56,900
context of your microphone test,
at least one, the 

498
00:24:56,900 --> 00:25:00,800
decentralization concepts and 
The strong one way of empowering

499
00:25:00,800 --> 00:25:03,300
the team. 
First of all, then another 

500
00:25:03,300 --> 00:25:05,700
interesting one in my opinion, 
is a culture of automation, 

501
00:25:05,700 --> 00:25:09,600
where microservices, especially 
nowadays with the rise of 

502
00:25:09,600 --> 00:25:12,200
serverless. 
Our business logic became 

503
00:25:12,200 --> 00:25:14,400
reduced drastically. 
The cognitive load because our 

504
00:25:14,400 --> 00:25:17,900
ways smaller the micro services 
that we are building, but at the

505
00:25:17,900 --> 00:25:21,500
same time you start to have a 
race instead on the operational 

506
00:25:21,500 --> 00:25:23,000
side. 
So you need to create 

507
00:25:23,000 --> 00:25:24,700
infrastructure as code. 
You need to create 

508
00:25:24,700 --> 00:25:29,300
observability, monitoring 
logging tracing and Do the other

509
00:25:29,300 --> 00:25:32,300
stuff that goes around? 
So the same thing is happening 

510
00:25:32,300 --> 00:25:34,300
with microphone test. 
The moment that you Embrace this

511
00:25:34,300 --> 00:25:37,300
to be the system, you are going 
towards that, but I think 

512
00:25:37,300 --> 00:25:40,700
microphone times are pretty new.
If before we had the single page

513
00:25:40,700 --> 00:25:41,700
application. 
For instance. 

514
00:25:41,700 --> 00:25:45,300
We had a binary situation where 
either your code is downloaded, 

515
00:25:45,300 --> 00:25:47,400
or it's not loaded. 
The only thing that could fail 

516
00:25:47,400 --> 00:25:50,500
is the backend now, especially 
on mobile website. 

517
00:25:50,500 --> 00:25:53,400
You can have part of your 
application that is loaded and 

518
00:25:53,400 --> 00:25:54,700
unloaded part. 
That is not. 

519
00:25:54,900 --> 00:25:58,700
And then I think this case we 
need to end, although situation.

520
00:25:58,900 --> 00:26:03,400
Gracefully, we cannot honestly, 
think about showing a 404 page 

521
00:26:03,400 --> 00:26:05,900
because the user didn't download
all the interface. 

522
00:26:05,900 --> 00:26:09,300
So, we need to think about that.
We need to also test these 

523
00:26:09,300 --> 00:26:12,200
things because the reality is is
not enough. 

524
00:26:12,200 --> 00:26:15,500
Just relying on Frameworks. 
We need to have solid testing. 

525
00:26:15,500 --> 00:26:18,700
Strategies would allow us to 
make sure that when something 

526
00:26:18,700 --> 00:26:21,700
happened to our application, 
everything would work anyway, 

527
00:26:22,000 --> 00:26:25,300
and that's basically a few of 
the principles that I put 

528
00:26:25,300 --> 00:26:28,700
together when I was working 
that, the other thing is trying,

529
00:26:28,800 --> 00:26:31,900
to be as technology agnostic as 
possible, because the moment 

530
00:26:31,900 --> 00:26:35,800
that you have a very opinionated
way, especially when you share 

531
00:26:35,800 --> 00:26:38,800
code across, like from 10th, you
may reach that, you are 

532
00:26:38,800 --> 00:26:42,400
cornering yourself in an angle 
that would be complicated to get

533
00:26:42,400 --> 00:26:45,200
away, and we require a lot of 
effort and maybe refactoring 

534
00:26:45,200 --> 00:26:48,500
around code, the for being 
mindful of what you are sharing,

535
00:26:48,500 --> 00:26:51,300
what you are not sharing and 
sometimes thinking that 

536
00:26:51,300 --> 00:26:55,100
duplication is not evil, 
sometimes could accelerate your 

537
00:26:55,100 --> 00:26:59,200
team and add some speed because 
Angling dependencies We'll share

538
00:26:59,200 --> 00:27:01,700
dependencies across teams. 
Means that you are creating an 

539
00:27:01,700 --> 00:27:05,100
external dependency for the team
and maintaining that in the long

540
00:27:05,100 --> 00:27:07,900
run with tens of teams. 
It may be non-trivial. 

541
00:27:08,100 --> 00:27:10,600
So sometimes a bit of 
duplication doesn't hurt. 

542
00:27:10,600 --> 00:27:12,500
Obviously. 
I'm not saying here that we 

543
00:27:12,500 --> 00:27:15,600
should duplicate everything, but
there are situation where you 

544
00:27:15,600 --> 00:27:18,500
need to be pragmatic. 
And see that duplication is not 

545
00:27:18,500 --> 00:27:20,700
going to affect the final 
result, too much. 

546
00:27:21,300 --> 00:27:23,400
Speaking about technology, 
agnostic. 

547
00:27:23,400 --> 00:27:26,200
I'm not very familiar with all 
this microphone and psychology. 

548
00:27:26,200 --> 00:27:29,400
So if you allow me asking some 
basic fundamental, Fashion these

549
00:27:29,400 --> 00:27:31,400
days, take example, web 
Technologies. 

550
00:27:31,400 --> 00:27:34,900
People are using either like few
JS react.js and all that. 

551
00:27:35,000 --> 00:27:37,400
So when you say about 
technology, agnostic do you mean

552
00:27:37,400 --> 00:27:40,500
that we should not base our 
microphone and architecture 

553
00:27:40,500 --> 00:27:43,200
using fundamental Frameworks 
like that, or is it something 

554
00:27:43,200 --> 00:27:45,900
different? 
It's a slightly different point 

555
00:27:45,900 --> 00:27:48,000
of view. 
So definitely you can use those 

556
00:27:48,000 --> 00:27:50,100
Frameworks. 
It's very important obviously, 

557
00:27:50,100 --> 00:27:53,000
for speeding up the development 
and it helps you to achieve your

558
00:27:53,000 --> 00:27:54,700
goals. 
When I talk about technology, 

559
00:27:54,700 --> 00:27:58,200
agnostic is when you have key 
point of your architecture, 

560
00:27:58,200 --> 00:28:02,500
trying Help the team basically 
to don't close them self in a 

561
00:28:02,508 --> 00:28:05,400
specific route. 
I don't have a very opinionated 

562
00:28:05,400 --> 00:28:07,200
way, just to give you an 
example. 

563
00:28:07,300 --> 00:28:09,400
Imagine that one of the main 
challenge when you deal with 

564
00:28:09,400 --> 00:28:12,700
Mike from the answer is creating
a UI consistency design system. 

565
00:28:12,700 --> 00:28:15,700
Definitely fit inside the micro 
service vehicle from times 

566
00:28:15,700 --> 00:28:18,700
world. 
Now, for that, what I recommend 

567
00:28:18,700 --> 00:28:21,700
more often than not is using web
components, because web 

568
00:28:21,700 --> 00:28:23,700
components are a technology 
agnostic. 

569
00:28:23,700 --> 00:28:27,300
You can use them either that 
you're using view JS or angular 

570
00:28:27,300 --> 00:28:28,600
or whatever. 
It's not a problem at all. 

571
00:28:28,800 --> 00:28:32,200
So yes, maybe is an effort or 
for learning if you're not 

572
00:28:32,200 --> 00:28:35,100
familiar with them, but in 
reality in the long run, you are

573
00:28:35,100 --> 00:28:38,700
creating a design system that 
can be reused in the future. 

574
00:28:38,700 --> 00:28:40,300
Despite. 
The turning point that the 

575
00:28:40,300 --> 00:28:43,200
company will have in the 
business will have the for if 

576
00:28:43,200 --> 00:28:45,600
today you have angular and 
tomorrow, you are moving to a 

577
00:28:45,608 --> 00:28:47,900
newer version of angular or 
another framework. 

578
00:28:48,000 --> 00:28:50,700
You won't have any problem 
because you can reuse the design

579
00:28:50,700 --> 00:28:52,900
system. 
I would say and argue that could

580
00:28:52,900 --> 00:28:55,600
be different in the case that 
you start to have a design 

581
00:28:55,600 --> 00:28:58,900
system for view because you're 
using View, and then you To 

582
00:28:58,900 --> 00:29:01,700
another frame or a new different
version of you and we require 

583
00:29:01,700 --> 00:29:04,600
you to change everything that 
definitely would be additional 

584
00:29:04,600 --> 00:29:07,000
effort that you want to do. 
When we did the zone. 

585
00:29:07,000 --> 00:29:10,000
For instance. 
One thing that we did was how to

586
00:29:10,000 --> 00:29:12,200
load every Mac front end, 
inside. 

587
00:29:12,200 --> 00:29:13,700
This thing called application 
shell. 

588
00:29:13,700 --> 00:29:17,200
Basically is the initial point 
where you have for the entire 

589
00:29:17,200 --> 00:29:20,900
user session, this application. 
Shall what it does is parsing 

590
00:29:20,900 --> 00:29:25,100
HTML page and appending the 
nodes that are related to a 

591
00:29:25,100 --> 00:29:27,900
microphone that inside. 
As you can see here. 

592
00:29:27,900 --> 00:29:31,800
We are not using Anything that 
was dedicated to react or view 

593
00:29:31,800 --> 00:29:34,100
or angular. 
We're using web standards 

594
00:29:34,100 --> 00:29:37,400
because we didn't want to 
preclude our self in the future 

595
00:29:37,400 --> 00:29:39,100
from changing technology or 
anything. 

596
00:29:39,300 --> 00:29:42,500
So as long as you got a 
framework that is outputting 

597
00:29:42,500 --> 00:29:45,900
HTML and JavaScript and 
potentially CSS is called work. 

598
00:29:45,900 --> 00:29:47,900
It's not going to create any 
issue. 

599
00:29:47,900 --> 00:29:52,100
So, that's the point where I 
think we need to be mindful and 

600
00:29:52,100 --> 00:29:53,500
trying to beat the current 
diagnostic. 

601
00:29:53,600 --> 00:29:55,700
There are other stuff that 
obviously doesn't make any 

602
00:29:55,700 --> 00:29:57,300
sense. 
It's through is fine. 

603
00:29:57,300 --> 00:29:59,900
Using a specific framework. 
Especially when you're creating 

604
00:29:59,900 --> 00:30:02,900
some views or other stuff, but 
for these kind of things, I 

605
00:30:02,900 --> 00:30:05,800
believe it's kind of important 
that when you Stitch the things 

606
00:30:05,800 --> 00:30:08,800
together and you share code 
trying to be as honest as 

607
00:30:08,800 --> 00:30:10,200
possible. 
And sometimes you won't be able 

608
00:30:10,200 --> 00:30:12,700
to do that because the context 
doesn't allow you to do that. 

609
00:30:12,700 --> 00:30:15,900
And that's fine because this 
trade-off you optimize for your 

610
00:30:15,900 --> 00:30:17,600
contest. 
You're not optimizing for the 

611
00:30:17,600 --> 00:30:20,700
world. 
Speaking about the app shell. 

612
00:30:20,700 --> 00:30:23,100
I'm very interested in this 
concept because it's like a 

613
00:30:23,100 --> 00:30:24,300
container, at the end of the 
day, right? 

614
00:30:24,300 --> 00:30:27,300
It's like the starting point 
where the view will be stitched 

615
00:30:27,300 --> 00:30:31,000
together and I That if you have 
a lot of microphones, maybe that

616
00:30:31,000 --> 00:30:34,000
say you have a user information,
you have shopping confirmation 

617
00:30:34,000 --> 00:30:38,400
or that all these different HTML
fragments can be generated using

618
00:30:38,400 --> 00:30:41,300
different libraries, different 
dependencies, maybe different 

619
00:30:41,300 --> 00:30:43,900
Frameworks internally. 
How do you ensure that the app 

620
00:30:43,900 --> 00:30:46,900
shell actually can make sure 
that everyone can work together 

621
00:30:46,900 --> 00:30:49,500
without having some Clash? 
Or some kind of broken 

622
00:30:49,500 --> 00:30:50,700
dependencies and things like 
that. 

623
00:30:51,400 --> 00:30:53,700
Yeah, that's a good point. 
So currently there are 

624
00:30:53,700 --> 00:30:56,700
Frameworks that helps you. 
The latest framers are helping 

625
00:30:56,700 --> 00:31:00,000
you to achieve that for me. 
Some now, thinking module 

626
00:31:00,000 --> 00:31:03,000
Federation with web Park that 
literally this week was 

627
00:31:03,000 --> 00:31:05,800
announced also be implemented 
also in es build. 

628
00:31:06,000 --> 00:31:08,900
So it would be not only on web 
part that makes available 

629
00:31:09,100 --> 00:31:11,900
lighter version of roll up. 
So it's getting a lot of 

630
00:31:11,900 --> 00:31:14,700
traction and it will be exactly 
this problem. 

631
00:31:14,900 --> 00:31:17,300
So you can use the technology 
you want. 

632
00:31:17,300 --> 00:31:20,500
They take care about wrapping 
the scope of your dependencies. 

633
00:31:20,600 --> 00:31:23,900
You can even share dependencies 
inside your system and 

634
00:31:23,900 --> 00:31:28,000
everything is nicely handled by 
the motive Federation, plug-in 

635
00:31:28,000 --> 00:31:29,800
that is available. 
When web talk about in the 

636
00:31:29,808 --> 00:31:31,500
future right now, they're 
building systems. 

637
00:31:31,700 --> 00:31:34,400
That is Prince. 
One way, in our case. 

638
00:31:34,400 --> 00:31:36,900
It was more coordination because
obviously as you said, we have 

639
00:31:36,900 --> 00:31:40,500
HTML fragments and we load one 
microscope a time. 

640
00:31:40,500 --> 00:31:43,000
So we don't have clashes between
teams for sure. 

641
00:31:43,200 --> 00:31:46,100
If we have to do that you have 
different ways to do this. 

642
00:31:46,300 --> 00:31:49,000
For instance. 
I know recipes, using framework 

643
00:31:49,000 --> 00:31:51,700
or Luigi framework. 
That is based on iframes and 

644
00:31:51,700 --> 00:31:53,600
then you wrap everything on an 
iPhone. 

645
00:31:53,800 --> 00:31:56,700
I know that many people could 
start to scream because I said 

646
00:31:56,700 --> 00:32:00,900
the magic word iframe this Most 
effective sandbox that we got 

647
00:32:00,900 --> 00:32:03,000
our web browser. 
So I know that maybe Is Not 

648
00:32:03,000 --> 00:32:06,600
Great to use that for certain 
use cases, but if you think 

649
00:32:06,600 --> 00:32:08,900
about the use case of software, 
you are an Enterprise 

650
00:32:08,900 --> 00:32:12,200
environment, you are in B2B 
system, not be to see, 

651
00:32:12,400 --> 00:32:14,600
extracting data from sub can be 
non-trivial. 

652
00:32:14,600 --> 00:32:18,100
So having a decent interface 
framework that handles with one 

653
00:32:18,100 --> 00:32:21,100
or two iframes in the view, the 
final outcome for the users is 

654
00:32:21,100 --> 00:32:24,200
probably less than a problem. 
Also, they can control the 

655
00:32:24,200 --> 00:32:27,200
environment where they work is 
not a similar environment. 

656
00:32:27,200 --> 00:32:30,400
So, overall I think, Think it 
could be a natural choice for 

657
00:32:30,400 --> 00:32:33,300
and Link potential memory leaks 
and for angling strong 

658
00:32:33,300 --> 00:32:35,200
boundaries between microphone 
test. 

659
00:32:35,400 --> 00:32:39,300
There is currently tc39. 
There is a proposal for one 

660
00:32:39,300 --> 00:32:42,500
thing called basically would be 
a lighter iframes. 

661
00:32:42,500 --> 00:32:45,900
If you want where the iframe is 
copying, the entire Dome object,

662
00:32:45,900 --> 00:32:48,400
with window. 
We arm will be lighter, but it's

663
00:32:48,400 --> 00:32:51,700
creating the sandbox of whatever
content is there. 

664
00:32:52,000 --> 00:32:53,700
Obviously, stealing second 
draft. 

665
00:32:53,700 --> 00:32:56,600
So there is still a long time 
before we see them in 

666
00:32:56,600 --> 00:33:00,500
JavaScript, if they come but 
they Idea sounds very appealing,

667
00:33:00,500 --> 00:33:02,600
and that could be a good fit for
my current density. 

668
00:33:02,800 --> 00:33:06,700
Meanwhile, I would say, module 
Federation is a place where I 

669
00:33:06,708 --> 00:33:08,900
would recommend to look at 
mainly because if you're 

670
00:33:08,900 --> 00:33:11,500
familiar with web pocket, the 
developer experience became 

671
00:33:11,500 --> 00:33:15,800
extremely familiar and simple 
for any developer to start with.

672
00:33:15,900 --> 00:33:18,900
There are other framework like 
single SP a another great 

673
00:33:18,900 --> 00:33:21,600
framework in my opinion that 
solve similar problems in 

674
00:33:21,600 --> 00:33:24,600
different ways and you can also 
mix and match with what 

675
00:33:24,600 --> 00:33:26,400
federation. 
But in general. 

676
00:33:26,400 --> 00:33:29,700
I would say trying to understand
your Context of what kind of 

677
00:33:29,700 --> 00:33:32,700
problems you are solving before 
you pick a framework because 

678
00:33:32,700 --> 00:33:35,700
it's not as simple as saying. 
Oh, I pick react if we can grow 

679
00:33:35,700 --> 00:33:38,800
because I'm a fan of it. 
But let's try to understand what

680
00:33:38,800 --> 00:33:40,100
kind of problems you are 
solving. 

681
00:33:40,100 --> 00:33:42,300
And how it's going to impact in 
your context. 

682
00:33:42,900 --> 00:33:47,000
Speaking about building a system
that has microfinance. 

683
00:33:47,200 --> 00:33:49,400
I'm speaking in terms of 
continuous delivery, continuous 

684
00:33:49,400 --> 00:33:51,800
integration. 
How do you actually assemble 

685
00:33:51,800 --> 00:33:53,600
this build and deployment 
pipeline? 

686
00:33:53,800 --> 00:33:56,500
Do you actually create multiple 
artifacts for different 

687
00:33:56,500 --> 00:33:58,200
microphones? 
And then you have another 

688
00:33:58,200 --> 00:34:00,000
pipeline? 
Actually stitch them together. 

689
00:34:00,100 --> 00:34:01,200
How does it work? 
Actually? 

690
00:34:01,900 --> 00:34:06,800
Yeah, so usually what you do is 
creating multiple pipelines, 1 /

691
00:34:06,800 --> 00:34:10,199
microphone tent and then the 
stitching depends which 

692
00:34:10,199 --> 00:34:12,600
composition you decide to have 
all my contacts. 

693
00:34:12,600 --> 00:34:14,199
You can have a server-side 
composition. 

694
00:34:14,199 --> 00:34:15,800
You can have an edge side 
composition. 

695
00:34:15,800 --> 00:34:18,500
You can have a client-side 
composition in the case of the 

696
00:34:18,500 --> 00:34:21,100
client-side composition. 
We have the application shell. 

697
00:34:21,100 --> 00:34:24,500
That is basically lazy loading, 
the different microphone pants. 

698
00:34:24,699 --> 00:34:27,600
Usually you have a container 
that is loaded and knows how to 

699
00:34:27,600 --> 00:34:31,400
display the Intense inside it. 
An example is much Federation is

700
00:34:31,400 --> 00:34:34,300
like that or single SK are doing
this for Edge side. 

701
00:34:34,300 --> 00:34:35,800
Composition. 
There is a language college 

702
00:34:35,800 --> 00:34:37,800
side. 
Include was released several 

703
00:34:37,800 --> 00:34:41,900
years ago, a bunch of companies 
including Akamai and Oracle that

704
00:34:41,900 --> 00:34:46,199
created these markup language. 
Yes, I what it does is basically

705
00:34:46,199 --> 00:34:48,600
leveraging. 
The transclusion concept where 

706
00:34:48,600 --> 00:34:51,600
you have a placeholder that is 
replaced by a microphone stand 

707
00:34:51,600 --> 00:34:54,699
at the edge in this case is 
happening everything at the CDN.

708
00:34:54,800 --> 00:34:58,500
So great for static content. 
You can also use nginx. 

709
00:34:58,700 --> 00:35:02,400
And varnish the problem that you
have in all of these approach is

710
00:35:02,400 --> 00:35:05,300
that the ASI. 
Markup language is not supported

711
00:35:05,300 --> 00:35:07,000
everywhere with the full 
specification. 

712
00:35:07,000 --> 00:35:09,900
Therefore Akamai is the only one
that is allowing to do that. 

713
00:35:10,100 --> 00:35:12,900
And when you have Dynamic 
content, you need to supplement 

714
00:35:12,900 --> 00:35:15,400
these with client-side, include 
that basically is the same 

715
00:35:15,400 --> 00:35:17,900
Constable transclusion, but is 
happening on the client side, 

716
00:35:18,100 --> 00:35:19,600
the developer experience is so 
so. 

717
00:35:19,600 --> 00:35:23,500
And you cannot definitely afford
more TCT and strategy with that 

718
00:35:23,700 --> 00:35:27,400
on the server side is that you 
basically have some potential 

719
00:35:27,400 --> 00:35:30,000
templates that you will be. 
She hosts and you filled with 

720
00:35:30,000 --> 00:35:32,400
data and then you server-side 
rendering everything on the 

721
00:35:32,400 --> 00:35:36,100
client or you can use what is 
called isomorphic or Universal 

722
00:35:36,100 --> 00:35:38,800
architecture, where you are 
basically having some code that 

723
00:35:38,800 --> 00:35:42,600
is running on the server and on 
the client for dynamic content, 

724
00:35:42,600 --> 00:35:45,400
for instance, and you can mix 
and match certain of those 

725
00:35:45,400 --> 00:35:47,000
options. 
In my opinion. 

726
00:35:47,100 --> 00:35:48,600
It really depends what you need 
to achieve. 

727
00:35:48,600 --> 00:35:51,400
If you want to have strong SEO, 
probably you're going with the 

728
00:35:51,400 --> 00:35:54,400
server-side rendering approach 
and there are for instance, some

729
00:35:54,400 --> 00:35:58,500
interesting twists there. 
I know that also next JS is do. 

730
00:35:58,700 --> 00:36:02,600
Into module Federation and 
spread because it means that we 

731
00:36:02,600 --> 00:36:05,800
are basically starting to get 
even more traction, with my 

732
00:36:05,800 --> 00:36:09,600
phone tents, and the moment that
you see ecosystem like web Park 

733
00:36:09,600 --> 00:36:14,300
and so on, it means that really 
we were able to show the benefit

734
00:36:14,300 --> 00:36:16,200
that these approach could take. 
Now. 

735
00:36:16,200 --> 00:36:18,100
The difficult part is 
understanding where the 

736
00:36:18,100 --> 00:36:20,700
boundaries are in my opinion, 
but it would be fun to see the 

737
00:36:20,700 --> 00:36:24,300
next few years speaking about 
implementing it correctly. 

738
00:36:24,400 --> 00:36:27,600
So what are some common 
challenges or anti patterns or 

739
00:36:27,600 --> 00:36:31,300
pitfalls that you I've seen from
the practice worldwide because 

740
00:36:31,300 --> 00:36:32,700
you have spoken with many 
people. 

741
00:36:33,200 --> 00:36:36,700
Yeah, many developers, when they
have multiple microphone times 

742
00:36:36,700 --> 00:36:39,400
in the same view and they need 
to communicate together. 

743
00:36:39,400 --> 00:36:42,700
The first thing that they think 
about is having a global State 

744
00:36:42,800 --> 00:36:46,800
and that is 70 and 90 pattern 
because the moment that you have

745
00:36:46,800 --> 00:36:50,500
a global State causing coupling 
only on the code wise, but also 

746
00:36:50,500 --> 00:36:53,300
the organization side, let's 
imagine we have three teams, 

747
00:36:53,300 --> 00:36:55,400
working, three different 
microphone tents with the global

748
00:36:55,400 --> 00:36:58,400
State and you are basically 
creating design time coupling. 

749
00:36:58,700 --> 00:37:02,100
Because what you do is I need to
add a new property, my Global 

750
00:37:02,100 --> 00:37:05,100
state or I need to change a 
global State and then I need to 

751
00:37:05,100 --> 00:37:08,300
coordinate and test or the other
microphone that moreover. 

752
00:37:08,300 --> 00:37:11,400
If you have a back-end team that
is working on some apis and you 

753
00:37:11,400 --> 00:37:14,200
consume multiple them and they 
change the contract. 

754
00:37:14,200 --> 00:37:16,900
Now you need to make sure that 
not only that the new Hunter is 

755
00:37:16,900 --> 00:37:19,100
working but also that I would 
the other microphone pants are 

756
00:37:19,100 --> 00:37:22,600
working and therefore, you are 
creating more communication 

757
00:37:22,600 --> 00:37:25,300
overhead and you need to get it 
together with the teams and make

758
00:37:25,300 --> 00:37:28,000
sure nothing is working. 
And he said if you keep the 

759
00:37:28,000 --> 00:37:31,500
state in, Inside the wreck front
end and you implement a pub sub 

760
00:37:31,500 --> 00:37:33,200
pattern. 
Where the communication is 

761
00:37:33,200 --> 00:37:37,200
happening through. 
Am even Demeter or custom events

762
00:37:37,200 --> 00:37:39,600
or signal library, or reactive 
stream. 

763
00:37:39,600 --> 00:37:42,700
So you're basically decoupling 
go system where the only thing 

764
00:37:42,700 --> 00:37:45,800
that you are exchanging is a 
contour the for an event. 

765
00:37:46,000 --> 00:37:47,500
You are the coupling first of 
all the team. 

766
00:37:47,500 --> 00:37:50,500
So as long as you respect, you 
know, what are the input of your

767
00:37:50,500 --> 00:37:53,000
microphone dance and the output 
of your microphone that everyone

768
00:37:53,000 --> 00:37:56,100
can plug without even bothering 
the team that is developing the 

769
00:37:56,100 --> 00:37:58,800
microphone dance but moreover in
an evolutionary The 

770
00:37:58,800 --> 00:38:02,100
architectural point of view you 
start to add you microphone 

771
00:38:02,100 --> 00:38:05,000
tense in the same view and they 
just check. 

772
00:38:05,000 --> 00:38:07,600
What are the events at the other
are bubbling around and just 

773
00:38:07,600 --> 00:38:10,500
plug themselves. 
And if you think about that is 

774
00:38:10,500 --> 00:38:12,700
the same difference between 
orchestration versus 

775
00:38:12,700 --> 00:38:15,000
choreography. 
We need the microservices word. 

776
00:38:15,000 --> 00:38:18,100
So you are trying to decouple 
that in that has a knockout 

777
00:38:18,100 --> 00:38:19,800
effect. 
Also on the team organization 

778
00:38:19,800 --> 00:38:21,700
where you maintain the 
boundaries of the team's, the 

779
00:38:21,700 --> 00:38:25,100
team can work at their own speed
testing and everything will be 

780
00:38:25,100 --> 00:38:27,800
simplified. 
That is first of all, one of the

781
00:38:27,800 --> 00:38:30,300
anti partner. 
I've seen the other thing that I

782
00:38:30,308 --> 00:38:33,900
have seen that the effective in 
my opinion, may be classified as

783
00:38:33,900 --> 00:38:36,600
an anti-pattern is having 
multiple Technologies in the 

784
00:38:36,600 --> 00:38:39,100
same application. 
Many people are thinking. 

785
00:38:39,100 --> 00:38:42,800
Oh, yeah, Mike from towns are a 
way to use View and angular and 

786
00:38:42,800 --> 00:38:45,000
react, all together with Stitch 
all together. 

787
00:38:45,000 --> 00:38:47,500
And off you go, you have your 
application, but what is 

788
00:38:47,500 --> 00:38:49,900
important in single page 
application server side, 

789
00:38:49,900 --> 00:38:52,700
rendering application, the 
performances are key. 

790
00:38:52,700 --> 00:38:56,100
Especially because now we saw a 
raise of the users that are 

791
00:38:56,100 --> 00:38:59,900
consuming our content on mobile 
devices, that Or 4G connection 

792
00:38:59,900 --> 00:39:03,200
5G now or 3g connection. 
Even we need to be mindful of 

793
00:39:03,207 --> 00:39:05,600
performance. 
My suggestion is Define. 

794
00:39:05,600 --> 00:39:08,400
What are the boundaries? 
So the team can work with react 

795
00:39:08,400 --> 00:39:12,800
16 or 17 wrecked, 18, angular, 
whatever, version doesn't 

796
00:39:12,800 --> 00:39:15,900
matter, but try to stick with 
the same thing. 

797
00:39:16,100 --> 00:39:19,100
If there is a situation where 
having for a certain period of 

798
00:39:19,100 --> 00:39:22,400
time multiple Frameworks can be 
helpful, it happen. 

799
00:39:22,400 --> 00:39:25,200
Those to us when we was working 
the Zone where we applied a 

800
00:39:25,200 --> 00:39:27,000
Strangler pattern for 
microphones. 

801
00:39:27,000 --> 00:39:30,800
And so we developed the first 
one, we push in production and 

802
00:39:30,800 --> 00:39:33,500
that was living alongside with 
our single page application. 

803
00:39:33,600 --> 00:39:35,400
Why that? 
Because we want to create an 

804
00:39:35,400 --> 00:39:38,400
identity of mindset for 
developers where they start to 

805
00:39:38,400 --> 00:39:42,100
push their coding production, 
not being in fear of having 

806
00:39:42,100 --> 00:39:45,300
changes in production and then 
create the mechanism around that

807
00:39:45,300 --> 00:39:48,400
for creating the confidence. 
So fast, see ICD creating 

808
00:39:48,400 --> 00:39:51,900
Connery releases, so you can 
shape the traffic on when things

809
00:39:51,900 --> 00:39:54,700
are going toward Legacy 
application, and potentially the

810
00:39:54,700 --> 00:39:56,800
possibility to switch all the 
traffic to the Legacy 

811
00:39:56,800 --> 00:39:58,400
application. 
That, you know, this could work.

812
00:39:58,800 --> 00:40:01,300
The 40s kind of mechanism 
created the confidence for 

813
00:40:01,300 --> 00:40:04,500
developers to move faster in 
their development experience and

814
00:40:04,500 --> 00:40:09,600
also gaining real data and data 
points to compare and apply to 

815
00:40:09,600 --> 00:40:12,400
improve their microphone. 
That feed that is invaluable 

816
00:40:12,400 --> 00:40:15,000
because the moment that you are 
capable to do this, you create 

817
00:40:15,000 --> 00:40:18,700
the a flywheel that will allow 
developers to learn and be 

818
00:40:18,700 --> 00:40:21,700
confident and create more code 
than the be faster in the 

819
00:40:21,700 --> 00:40:23,300
release. 
At the end of the day. 

820
00:40:23,300 --> 00:40:26,500
We saw that we move from few 
development per month, to tens 

821
00:40:26,500 --> 00:40:29,200
of development per month. 
Just because of It's because the

822
00:40:29,200 --> 00:40:32,500
developers has the possibility 
in a matter of seconds to turn 

823
00:40:32,500 --> 00:40:35,900
off all the traffic or reduce 
the traffic on specific browsers

824
00:40:35,900 --> 00:40:38,900
or specific devices. 
And that for me was fantastic 

825
00:40:38,900 --> 00:40:41,800
because basically we achieved 
after a long time one of the 

826
00:40:41,800 --> 00:40:43,500
main goals that we had with this
approach. 

827
00:40:44,100 --> 00:40:46,800
So thanks for sharing the tips. 
For example, you start with 

828
00:40:46,900 --> 00:40:49,100
small thing, right? 
Gain confidence, build the 

829
00:40:49,100 --> 00:40:52,500
flywheel, iterative mindset. 
So any other tips for people who

830
00:40:52,500 --> 00:40:54,900
are sold into this idea. 
Okay, microphone, and let's 

831
00:40:54,900 --> 00:40:58,400
start it because for example, in
microservice world breaking up 

832
00:40:58,500 --> 00:41:00,700
Manolis, it's also not a easy 
thing. 

833
00:41:00,900 --> 00:41:04,200
You would start probably by 
identifying seems or fracture 

834
00:41:04,200 --> 00:41:07,000
planes or maybe Strangler 
pattern. 

835
00:41:07,200 --> 00:41:09,700
What are some of the tips that 
you can give for people who want

836
00:41:09,700 --> 00:41:12,500
to try this on their monolith 
front end so to speak. 

837
00:41:13,000 --> 00:41:15,500
So let's assume that a theme or 
company. 

838
00:41:15,500 --> 00:41:18,100
Finally, decide that microphone 
tenses, the right architecture 

839
00:41:18,100 --> 00:41:20,900
for them because that is the 
first thing I would say, first, 

840
00:41:20,900 --> 00:41:23,300
understand if you really can 
provide the benefits to your 

841
00:41:23,300 --> 00:41:27,200
organization, but secondly, I 
would say if you identified, my 

842
00:41:27,200 --> 00:41:30,700
contents can be helpful. 
Start with a nice session in 

843
00:41:30,700 --> 00:41:33,400
front of the Whiteboard or 
digital whiteboard nowadays, 

844
00:41:33,500 --> 00:41:37,900
where you are basically 
defining, what are your domains 

845
00:41:37,900 --> 00:41:41,100
as trying to understand how they
fit with the current 

846
00:41:41,100 --> 00:41:43,800
organization. 
If you need to make changes when

847
00:41:43,800 --> 00:41:48,600
you identified one, trying to 
take one vertical, one boundary 

848
00:41:48,700 --> 00:41:51,200
that will allow you to test your
assumptions. 

849
00:41:51,400 --> 00:41:54,200
It doesn't have to be the most 
complex one and I would 

850
00:41:54,200 --> 00:41:57,800
recommend not taking one with 
new features because otherwise 

851
00:41:57,800 --> 00:41:59,300
there are too many. 
No moving Parts. 

852
00:41:59,500 --> 00:42:01,100
I preferred starting with 
something. 

853
00:42:01,100 --> 00:42:03,600
That is Consolidated. 
This they are you know, how it 

854
00:42:03,600 --> 00:42:05,400
works. 
Deeply, you are a domain expert.

855
00:42:05,400 --> 00:42:06,900
You already developing another 
way. 

856
00:42:07,100 --> 00:42:11,900
So take that start small and 
create everything end-to-end and

857
00:42:11,900 --> 00:42:13,400
trust me. 
You're not going to have the 

858
00:42:13,400 --> 00:42:16,800
perfect solution a first time 
but you will learn a lot during 

859
00:42:16,800 --> 00:42:19,900
the journey and when you have 
done that share the knowledge 

860
00:42:19,900 --> 00:42:22,300
back to the company and start to
have contribution for other 

861
00:42:22,300 --> 00:42:25,600
people and then when you have 
that, you continue this approach

862
00:42:25,600 --> 00:42:28,200
and start to improve slowly but 
steady one thing that I 

863
00:42:28,200 --> 00:42:30,700
recommend And especially the 
beginning is having enough 

864
00:42:30,700 --> 00:42:32,400
bandwidth and keeping your 
backlog. 

865
00:42:32,400 --> 00:42:36,200
A bit of time for reviewing the 
CI CD because that at the 

866
00:42:36,207 --> 00:42:38,800
beginning, we will potentially 
slow you down. 

867
00:42:38,800 --> 00:42:42,100
So you need to refine a string 
line, the key points, and 

868
00:42:42,100 --> 00:42:46,200
definitely the team should be 
empowered to change its own CI 

869
00:42:46,200 --> 00:42:50,100
CD because in reality, you need 
to build it only your code. 

870
00:42:50,300 --> 00:42:52,800
The moment that you don't know 
how to build it how to operate, 

871
00:42:52,800 --> 00:42:55,000
it is impossible to, you can 
maintain that code. 

872
00:42:55,100 --> 00:42:58,000
So it's very important also 
microphone 10th from the 

873
00:42:58,000 --> 00:43:00,900
learning of We had on 
microservices that the team is 

874
00:43:00,900 --> 00:43:04,200
responsible for that. 
If we do these I think they can 

875
00:43:04,200 --> 00:43:07,700
start to achieve some great 
result in short iterations and 

876
00:43:07,700 --> 00:43:10,700
then continue constantly to do 
that and accelerate as fast as 

877
00:43:10,700 --> 00:43:12,400
you can because that would be 
contagious. 

878
00:43:12,600 --> 00:43:15,500
Everyone would like to do that 
and when they see the benefit of

879
00:43:15,500 --> 00:43:17,900
it, the see that they are 
independent, they don't have to 

880
00:43:17,900 --> 00:43:20,700
coordinate any more and they can
deployed. 

881
00:43:20,700 --> 00:43:23,900
A small portion of their 
business logic without retesting

882
00:43:23,900 --> 00:43:26,800
the direct creation. 
Then I think we would be in a 

883
00:43:26,800 --> 00:43:29,600
position where you start to see 
the If you took this approach 

884
00:43:30,100 --> 00:43:33,200
Luka, you also wrote a book 
about microfinance, right? 

885
00:43:33,200 --> 00:43:35,200
The title is building micro 
front ends. 

886
00:43:35,500 --> 00:43:37,100
So, can you share a little bit 
about the book? 

887
00:43:37,200 --> 00:43:39,100
What can people expect by 
reading the book? 

888
00:43:39,600 --> 00:43:40,400
Yeah. 
Absolutely. 

889
00:43:40,400 --> 00:43:43,800
So the book currently is in 
early release on the O'Reilly 

890
00:43:43,800 --> 00:43:46,900
website. 
They will be ready by Q4 this 

891
00:43:46,900 --> 00:43:49,600
year. 
The book basically is a work of 

892
00:43:49,600 --> 00:43:54,700
two years of my life where I not
only learn a lot with the Zone, 

893
00:43:54,900 --> 00:43:58,500
but I deliberately spend time 
talking with people and The 

894
00:43:58,508 --> 00:44:01,700
standing there challenges and 
see if my thought process was 

895
00:44:01,700 --> 00:44:04,800
applicable in other context, 
because in reality doesn't was 

896
00:44:04,800 --> 00:44:06,800
one context. 
Obviously at the world is way 

897
00:44:06,800 --> 00:44:08,400
more complex than having just 
one. 

898
00:44:08,900 --> 00:44:13,200
I saw a lot of benefit I change 
and twist my thought. 

899
00:44:13,200 --> 00:44:16,900
Process several times. 
I have seen people applying what

900
00:44:16,900 --> 00:44:19,200
I was suggesting and being 
successful. 

901
00:44:19,500 --> 00:44:23,100
Therefore if you expect a book 
where you find tons of code on 

902
00:44:23,100 --> 00:44:25,600
how to implement different 
framework, is exactly what you 

903
00:44:25,600 --> 00:44:26,500
want. 
Find inside. 

904
00:44:26,500 --> 00:44:30,800
My book, what I'm sharing. 
More an approach for building. 

905
00:44:30,800 --> 00:44:33,300
Mike, front-ends and learning 
the thought process. 

906
00:44:33,300 --> 00:44:35,600
Because when you learn that, if 
tomorrow, there is a new 

907
00:44:35,600 --> 00:44:39,200
technology, you don't have to 
relearn the basics, you know, 

908
00:44:39,200 --> 00:44:41,600
how to apply the core concept 
and that use. 

909
00:44:41,900 --> 00:44:45,100
I was very inspired by some 
human book on building 

910
00:44:45,100 --> 00:44:48,200
microservices. 
And I try to keep exactly a 

911
00:44:48,200 --> 00:44:51,600
similar approach where you were 
more on the code side. 

912
00:44:51,600 --> 00:44:53,100
Obviously up. 
There are some code snippet. 

913
00:44:53,100 --> 00:44:55,500
There is a chapter where I 
showed implementation of a 

914
00:44:55,500 --> 00:44:57,200
microphone tense. 
A couple of different 

915
00:44:57,200 --> 00:45:00,600
implementation, but the idea is 
talking about organization 

916
00:45:00,600 --> 00:45:04,000
structure, how to sell my 
contents inside the company, how

917
00:45:04,000 --> 00:45:06,700
to migrate a monolith to 
microphone tense. 

918
00:45:06,700 --> 00:45:09,700
What are the challenges were 
going to face how to integrate 

919
00:45:09,700 --> 00:45:12,600
with back-end and showing 
different patterns to do that? 

920
00:45:12,900 --> 00:45:16,500
The principles behind microphone
tense and how to use them across

921
00:45:16,500 --> 00:45:19,600
the entire time steps. 
And also, there is a chapter and

922
00:45:19,600 --> 00:45:23,100
finishing right now, that is a 
comparison of all the different 

923
00:45:23,100 --> 00:45:26,500
microphone 10th approaches 
client-side server, side edge 

924
00:45:26,500 --> 00:45:29,600
side, and the challenges that 
you He's in all of them. 

925
00:45:29,800 --> 00:45:33,000
Basically, this two years for me
was extremely helpful because I 

926
00:45:33,000 --> 00:45:35,800
was able to see different 
companies approaching the 

927
00:45:35,800 --> 00:45:38,900
challenge that they face. 
I was able to speak with several

928
00:45:38,900 --> 00:45:42,000
conferences and sharing what I 
have learned and a different 

929
00:45:42,000 --> 00:45:44,700
approach and talking with people
that are doing microphone test 

930
00:45:44,700 --> 00:45:48,000
before potentially longer than 
me and see their point of view 

931
00:45:48,000 --> 00:45:51,500
and see how I was approaching 
similar problems in different 

932
00:45:51,500 --> 00:45:54,000
angles. 
I think I'm very proud of that. 

933
00:45:54,000 --> 00:45:57,500
That many of the thought that I 
shared, I create a mental model 

934
00:45:57,500 --> 00:45:59,700
for approaching. 
My contents called the decision 

935
00:45:59,700 --> 00:46:03,200
framework that I saw the booze 
embracing several talks and by 

936
00:46:03,200 --> 00:46:06,400
the community widely. 
Therefore, I'm very proud of 

937
00:46:06,400 --> 00:46:09,900
this contribution, because 
obviously it's not easy creating

938
00:46:09,900 --> 00:46:12,800
a new architecture, nowadays 
because we have a lot of 

939
00:46:12,800 --> 00:46:15,400
architectures out there that are
not changing very often. 

940
00:46:15,600 --> 00:46:18,100
It's not like a frame of that. 
You just release a new framework

941
00:46:18,300 --> 00:46:20,800
and that reduction is there for 
sticking and creating the 

942
00:46:20,800 --> 00:46:23,900
foundation for that is extremely
complex seen. 

943
00:46:23,900 --> 00:46:26,300
That these specific chunk of 
work that they have done. 

944
00:46:26,300 --> 00:46:29,500
That basically is the result of 
six years of Work stick very 

945
00:46:29,500 --> 00:46:32,800
well inside the community and 
was widely used and made me very

946
00:46:32,800 --> 00:46:35,800
proud of the Journey of Dawn. 
And makes me think that the 

947
00:46:35,800 --> 00:46:38,600
thing that I'm reversing inside 
the book, that would be more 

948
00:46:38,600 --> 00:46:41,800
than 300 pages. 
Long will contain the size that 

949
00:46:41,800 --> 00:46:44,300
the community is looking for 
sounds, very exciting. 

950
00:46:44,300 --> 00:46:47,200
I'm looking forward to reading 
the book in queue for everyone 

951
00:46:47,200 --> 00:46:50,000
who are really interested in 
learning more about micro front 

952
00:46:50,000 --> 00:46:52,900
ends, the architecture, the 
decision Frameworks and things 

953
00:46:52,900 --> 00:46:54,900
like that. 
Make sure to check that out. 

954
00:46:54,900 --> 00:46:57,000
So Luca is been a pleasure 
talking to you. 

955
00:46:57,100 --> 00:46:59,900
I have one last question. 
For my guests normally, which is

956
00:46:59,900 --> 00:47:02,200
to talk about your tree 
technical leadership. 

957
00:47:02,200 --> 00:47:04,300
Wisdom. 
Would you mind sharing some of 

958
00:47:04,300 --> 00:47:06,800
the wisdom that you have learned
from your career Journey? 

959
00:47:07,600 --> 00:47:09,900
Absolutely. 
So one thing that many people 

960
00:47:09,900 --> 00:47:13,400
are not familiar with, but for 
me was a key turning point in my

961
00:47:13,400 --> 00:47:15,400
career. 
I was reading a book called The 

962
00:47:15,400 --> 00:47:18,700
Spirit of casein in Japanese. 
Kaizen means continuous 

963
00:47:18,700 --> 00:47:20,800
Improvement. 
This is the practice that you 

964
00:47:20,800 --> 00:47:24,700
can apply your daily life. 
But also it can be applicable on

965
00:47:24,700 --> 00:47:27,800
your day-to-day work for me. 
It was fantastic because 

966
00:47:27,800 --> 00:47:31,500
understanding We'd small things,
you can really achieve great 

967
00:47:31,500 --> 00:47:33,600
results. 
Have me to shape My Mind. 

968
00:47:33,600 --> 00:47:36,600
Set an example for these, maybe 
seems very simple. 

969
00:47:36,600 --> 00:47:38,500
But for me was extremely 
powerful. 

970
00:47:38,800 --> 00:47:42,700
I started to read during commute
time a chapter per day, and at 

971
00:47:42,700 --> 00:47:45,900
the end of the year, you end up 
reading 20 books. 

972
00:47:46,300 --> 00:47:49,600
So yes, it's literally 20 30 
minutes of reading. 

973
00:47:49,600 --> 00:47:53,100
But is, every day is constant. 
You're creating a habit and at 

974
00:47:53,100 --> 00:47:55,700
the end of the day, you have a 
big result and the same thing. 

975
00:47:55,700 --> 00:47:57,800
I started to apply an everything
I'm doing. 

976
00:47:57,800 --> 00:47:59,800
So for instance. 
If I know that I have a large 

977
00:47:59,800 --> 00:48:02,800
commitment, I start to break my 
commitment in small fixed. 

978
00:48:02,800 --> 00:48:05,300
Then they know that maybe, 
sometimes there are bitter pills

979
00:48:05,300 --> 00:48:08,800
that I don't want to take, but I
have to therefore, if I'm able 

980
00:48:08,800 --> 00:48:12,400
to split them in, multiple days 
and taking meaningful stuff to 

981
00:48:12,400 --> 00:48:13,700
see a progress of what I'm 
doing. 

982
00:48:14,200 --> 00:48:17,200
Definitely the end of the day, 
we see great result and these 

983
00:48:17,200 --> 00:48:19,100
are also the same way how I take
all my books. 

984
00:48:19,100 --> 00:48:20,800
This one is the second book that
I'm writing. 

985
00:48:20,800 --> 00:48:25,000
I started dividing chapters and 
that paragraphs, the try to take

986
00:48:25,000 --> 00:48:27,700
all small things because at the 
end of the day, I see that the 

987
00:48:27,700 --> 00:48:30,500
end of the month of 40 pages 
because every day I wrote a 

988
00:48:30,500 --> 00:48:32,300
small part that is the first 
one. 

989
00:48:32,700 --> 00:48:35,300
The other thing is engaging with
the community. 

990
00:48:35,500 --> 00:48:38,000
Don't be afraid to speak with 
people. 

991
00:48:38,200 --> 00:48:40,600
It doesn't matter the role. 
It doesn't matter what religion 

992
00:48:40,600 --> 00:48:42,500
that they are. 
The reality is. 

993
00:48:42,500 --> 00:48:46,000
You can always learn from them 
because maybe they have an angle

994
00:48:46,000 --> 00:48:48,800
of the same thing that you are 
convinced is right in your head 

995
00:48:48,800 --> 00:48:52,300
that you didn't explore for me. 
I've been having this open mind 

996
00:48:52,300 --> 00:48:56,000
on approaching everyone and 
listening deeply on their point 

997
00:48:56,000 --> 00:48:58,300
of view. 
It's extremely powerful because 

998
00:48:58,400 --> 00:49:01,800
cuz then you gain a new inside 
your head and you start to 

999
00:49:01,800 --> 00:49:04,200
elaborate that maybe you don't 
use tomorrow. 

1000
00:49:04,500 --> 00:49:07,600
Maybe know you won't use this 
year if you using three years 

1001
00:49:07,600 --> 00:49:10,800
time, but your brain will pick 
it up and I would be extremely 

1002
00:49:10,800 --> 00:49:13,000
powerful. 
The last thing that I would say,

1003
00:49:13,000 --> 00:49:15,600
I keep back to the community. 
That's how I greet. 

1004
00:49:15,600 --> 00:49:18,200
You, personally, I said, I 
myself thought person. 

1005
00:49:18,200 --> 00:49:22,000
Therefore what I did was 
learning from others and sharing

1006
00:49:22,000 --> 00:49:26,000
back to others, and I think that
was one of the coolest thing 

1007
00:49:26,000 --> 00:49:27,600
that I have ever done in my 
life. 

1008
00:49:27,700 --> 00:49:30,800
I constantly Do that try to 
write blog posts to record 

1009
00:49:30,800 --> 00:49:33,600
videos. 
I try to do talks, not because 

1010
00:49:33,600 --> 00:49:36,300
I'm interesting about the name 
of because I have this forever 

1011
00:49:36,300 --> 00:49:39,100
tapped with the community that I
try to feel it. 

1012
00:49:39,100 --> 00:49:41,900
Somehow all the time spending 
outside. 

1013
00:49:41,900 --> 00:49:45,800
My job doing external activities
is more for trying to feel that 

1014
00:49:46,000 --> 00:49:48,700
because if it wasn't for the 
community, I wouldn't be in the 

1015
00:49:48,707 --> 00:49:51,700
place where I am right now and 
therefore I won't the next 

1016
00:49:51,700 --> 00:49:55,500
person that is trying to take 
this path will have a smoother 

1017
00:49:55,500 --> 00:49:57,300
path than I had back in the 
days. 

1018
00:49:57,700 --> 00:49:59,000
Thanks for sharing. 
The wisdom. 

1019
00:49:59,000 --> 00:50:00,500
Speaking about giving back to 
community. 

1020
00:50:00,500 --> 00:50:02,200
Again. 
Thanks for being part of this 

1021
00:50:02,200 --> 00:50:05,100
podcast. 
So Luca, if people want to know 

1022
00:50:05,100 --> 00:50:07,600
more about you, they want to 
discuss about micro front ends, 

1023
00:50:07,600 --> 00:50:09,700
or maybe your book. 
Is there a place where they can 

1024
00:50:09,700 --> 00:50:11,400
reach you online. 
Absolutely. 

1025
00:50:11,400 --> 00:50:14,500
So LinkedIn or Twitter. 
I'm extremely active in both of 

1026
00:50:14,500 --> 00:50:16,400
them. 
So, feel free to add me. 

1027
00:50:16,600 --> 00:50:18,900
My first name surname in both of
them? 

1028
00:50:18,900 --> 00:50:23,300
So you can find me very quickly 
overall, if you search online or

1029
00:50:23,300 --> 00:50:25,600
especially on YouTube, you find 
tons of books that they have 

1030
00:50:25,600 --> 00:50:27,600
done on that. 
So feel free to reach me out 

1031
00:50:27,600 --> 00:50:30,000
anytime. 
As you can see, I'm a very 

1032
00:50:30,000 --> 00:50:33,200
approachable person. 
I definitely reply to everyone. 

1033
00:50:33,400 --> 00:50:36,600
There are a lot of nice stories 
that happen after opening to the

1034
00:50:36,600 --> 00:50:39,100
community and say yes to 
everything that obviously we 

1035
00:50:39,100 --> 00:50:42,000
don't have time to tell, but I 
can tell you, that is extremely 

1036
00:50:42,000 --> 00:50:44,700
cool and therefore, feel free to
reach me out anytime. 

1037
00:50:44,700 --> 00:50:46,400
I'm more than happy to answer 
all your questions. 

1038
00:50:46,900 --> 00:50:47,700
Thanks again. 
Look at. 

1039
00:50:47,700 --> 00:50:49,500
So it's really nice to have a 
chat with you. 

1040
00:50:49,700 --> 00:50:51,000
I wish you good luck with the 
book. 

1041
00:50:51,300 --> 00:50:53,200
Thank you very and have a nice 
day. 

1042
00:50:56,000 --> 00:50:59,400
Thank you for listening to this 
episode and for staying right 

1043
00:50:59,400 --> 00:51:02,200
till the end. 
If you highly enjoyed, please 

1044
00:51:02,200 --> 00:51:05,000
share it with your friends and 
colleagues who you think would 

1045
00:51:05,000 --> 00:51:07,800
also benefit from listening to 
this episode. 

1046
00:51:08,000 --> 00:51:10,900
And if you're new to the 
podcast, make sure to subscribe 

1047
00:51:10,900 --> 00:51:13,800
and leave me your valuable 
review and feedback. 

1048
00:51:14,000 --> 00:51:17,700
It really really helps me a lot 
in order to grow this podcast 

1049
00:51:17,700 --> 00:51:20,200
better. 
You can also find the full show 

1050
00:51:20,200 --> 00:51:23,800
notes of this conversation on 
the episode page at technology. 

1051
00:51:23,800 --> 00:51:27,700
Know the death website including
The full transcript, interesting

1052
00:51:27,700 --> 00:51:30,900
quotes and links to the 
resources and mentions from the 

1053
00:51:30,900 --> 00:51:33,600
conversation. 
And lastly, make sure to 

1054
00:51:33,600 --> 00:51:36,400
subscribe to the shows mailing 
list on package, you know, the 

1055
00:51:36,400 --> 00:51:39,500
deaf to get notified for any 
future episodes. 

1056
00:51:39,800 --> 00:51:42,600
Stay tuned for the next 
technique Journal episode. 

1057
00:51:42,600 --> 00:51:44,300
And until then. 
Goodbye.