WEBVTT

1
00:00:06.320 --> 00:00:10.439
Hey, welcome to React Round Up, the podcast where we keep you updated

2
00:00:10.480 --> 00:00:15.679
on all things React related. This
show is sponsored by ray Gun and produced

3
00:00:15.679 --> 00:00:19.239
by Top and Doves and Onvoid.
Top and Doves is very great Top and

4
00:00:19.280 --> 00:00:23.320
Doves, so get top and pay
and recognition for working on interesting problems and

5
00:00:23.359 --> 00:00:28.960
make meaningful community contributions. An Onvoid
which provides remote design and software development services

6
00:00:28.960 --> 00:00:32.840
on a task basis, so clients
only pay when tests are delivered and approved.

7
00:00:33.399 --> 00:00:39.240
In today's episode, we'll talk about
bits and composable software. My name

8
00:00:39.399 --> 00:00:44.159
is Lucas Paganini, your host and
podcast Joining me in today's episode is also

9
00:00:44.280 --> 00:00:51.600
the host Chris Ruin, Hello everybody, and our special guest Gilad Shoham,

10
00:00:51.799 --> 00:00:56.479
which is the VP of Engineering at
bit dot dov. Hi, Nice to

11
00:00:56.520 --> 00:00:59.600
meet you everyone. It's great to
have you on the show. It's not

12
00:00:59.640 --> 00:01:04.120
always we get the VP of engineering
off the company in the show. Cool.

13
00:01:04.400 --> 00:01:07.920
Thank you. Hey, folks,
this is Charles Maxwell. I've been

14
00:01:07.920 --> 00:01:12.040
talking to whole bunch of people that
want to update their resume and find a

15
00:01:12.040 --> 00:01:15.719
better job, and I figure,
well, why not just share my resume.

16
00:01:15.799 --> 00:01:21.400
So if you go to top endevs
dot com slash resume enter your name

17
00:01:21.439 --> 00:01:25.000
and email address. Then you'll get
a copy of the resume that I use

18
00:01:25.359 --> 00:01:30.359
that I've used through freelancing through most
of my career as I've kind of refined

19
00:01:30.400 --> 00:01:33.959
it and tweaked it to get me
the jobs that I want. Like I

20
00:01:33.959 --> 00:01:37.959
said, topendevs dot com slash resume
will get you that, and you can

21
00:01:38.000 --> 00:01:41.879
just kind of use the formatting.
It comes in word and pages formats and

22
00:01:41.920 --> 00:01:49.000
you can just fill it in from
there. So gild could you please give

23
00:01:49.040 --> 00:01:53.680
a pitch to the audience about bit
death, what it is, why should

24
00:01:53.680 --> 00:01:59.599
anyone care about it? And then
we can get into all the knits and

25
00:01:59.599 --> 00:02:06.079
bits of about it. Sure of
course. So bit is basically a tool

26
00:02:06.159 --> 00:02:14.560
chain to build composable software. It
helped you to improve reuse and sharing components,

27
00:02:15.840 --> 00:02:23.840
increased composibility and eventually getting more speed
of development, more velocity, uh,

28
00:02:23.879 --> 00:02:32.520
and more consistency because your product that's
uh, that's like an eye level.

29
00:02:34.159 --> 00:02:38.280
We are working on these problems for
the past almost ten years now,

30
00:02:39.159 --> 00:02:46.759
and we'll focused not only on technical
and technological issues around this topic, but

31
00:02:46.800 --> 00:02:54.319
also around philosophy and around methodology of
how you can improve you have life cycle

32
00:02:54.759 --> 00:03:04.360
workflow h and there are many many
sub or blames of issues along the way

33
00:03:04.759 --> 00:03:09.000
in order to make better composibility,
sharing and division cool. So the main

34
00:03:09.080 --> 00:03:21.080
premise is about composing software nice.
What exactly does Betta offers that I can't

35
00:03:21.120 --> 00:03:27.000
get with other solutions already existing in
the markets such as mono repos like Turbo

36
00:03:27.039 --> 00:03:32.560
repos and nx are just yeah,
so at least that's where my mind took

37
00:03:32.599 --> 00:03:37.639
me to to mono repos. But
I'm not even sure if that's a good

38
00:03:37.680 --> 00:03:45.919
comparison to make. First, it's
a great comparison the different comparison or different

39
00:03:46.479 --> 00:03:54.319
category of product that are that are
kind of compared against bit. So first,

40
00:03:55.960 --> 00:04:02.439
so fist, let's make some high
level presentation of how bit is composed

41
00:04:02.719 --> 00:04:09.639
itself. So bat is composed from
two different main parts. One is BATU

42
00:04:09.960 --> 00:04:13.719
the c l I, and the
other is bit Cloud, which is a

43
00:04:13.759 --> 00:04:17.240
SASS platform. It's very very similar
to to get the guitar. You have

44
00:04:17.360 --> 00:04:25.439
Beats as a CLI. It's an
open source project which manage your components and

45
00:04:25.759 --> 00:04:30.279
the cloud which manage which is like
kind of a hosting platform for components and

46
00:04:30.600 --> 00:04:42.759
including additional enterprise features like security staff
and the hosting and c I and searching.

47
00:04:44.279 --> 00:04:49.759
So when talking about tools like NX
and two burripo, first they are

48
00:04:49.800 --> 00:04:58.720
only handling the local development and they
are not doing anything related to the sharing

49
00:04:58.839 --> 00:05:02.560
later on. So for example,
the entire discovery experience, how we can

50
00:05:02.639 --> 00:05:09.319
find components, how I can experience
my components, check what fits me,

51
00:05:10.439 --> 00:05:15.480
analytics about components, usages, and
stuff like this, which all these are

52
00:05:15.759 --> 00:05:23.079
stuff that that all the mono reporters
are not dealing with. Another very important

53
00:05:23.399 --> 00:05:32.680
distinction is that mono repotools are built
around rippers, which basically means they are

54
00:05:33.839 --> 00:05:41.399
the aim to make more centralization of
your workflow, while we in bit believe

55
00:05:41.639 --> 00:05:46.879
in kind of the opposite direction of
this centralize everything. So in Bit,

56
00:05:46.000 --> 00:05:53.360
many times many users don't use repo
at all, not even like a regularly,

57
00:05:53.439 --> 00:05:58.199
but not using Git at all,
because we came up with kind of

58
00:05:58.240 --> 00:06:02.839
a concept, which is we call
it sometimes like a disposable workspace, which

59
00:06:02.959 --> 00:06:08.319
you just make a new four there, build your feature there, and then

60
00:06:08.399 --> 00:06:15.000
the lead this workspace after it.
And this is possible because of one of

61
00:06:15.040 --> 00:06:21.879
the major features on bit, which
is the import feature, which means you

62
00:06:21.920 --> 00:06:29.600
can take any component from any from
any workspace, any project anywhere in your

63
00:06:29.680 --> 00:06:36.839
organization, and you can develop it
in any other workspace or project, So

64
00:06:36.879 --> 00:06:44.360
you can kind of clone the source
code of different components into your own temporary

65
00:06:44.399 --> 00:06:49.480
workspace, develop them there, and
then deleat the entire the entire workspace.

66
00:06:51.680 --> 00:06:59.120
Another important distinction between the monoreporters and
BIT, I think, is that the

67
00:06:59.199 --> 00:07:10.439
mono reports are are are basically doing
as a automation for scripts from outside that

68
00:07:10.600 --> 00:07:19.360
run on multiple packages or and linking
between the packages, while BIT is managing

69
00:07:19.399 --> 00:07:26.319
your entire life cycle of your component, which means when you do compilation,

70
00:07:26.800 --> 00:07:32.319
for example, on an NX project, the compilation script are basically outside the

71
00:07:32.360 --> 00:07:39.480
outside NX and NX is just calling
them to run them on different packages,

72
00:07:39.800 --> 00:07:45.000
while on BIT this is part of
the component metadata. And we will discuss

73
00:07:45.040 --> 00:07:50.920
this and in a minute. And
the third important distinction is the level of

74
00:07:50.959 --> 00:08:01.680
granularity the tools can handle. So
the monoycle tools built to handleckages, when

75
00:08:01.800 --> 00:08:09.480
we build BITS to manage components,
which is many times they are very similar

76
00:08:09.439 --> 00:08:16.040
in the technical aspect, but usually
it's a different level of granularity. So

77
00:08:16.079 --> 00:08:20.959
for example, if you have let's
say something like a design system, you

78
00:08:20.000 --> 00:08:24.680
have one package for design system,
but it is fifty components, and we

79
00:08:24.959 --> 00:08:31.240
try to make we build at a
tool to make each component like an individual

80
00:08:33.000 --> 00:08:37.720
entity, with its own history,
its own package, its own versioning,

81
00:08:39.120 --> 00:08:43.879
it's on everything. So if you
try to make like an NX triple with

82
00:08:45.279 --> 00:08:50.039
like fifty components fifty packages, it's
fine. But if you take these fifty

83
00:08:50.039 --> 00:08:54.919
packages, which sometimes might be composed
from ten thousands from a thousand components,

84
00:08:56.440 --> 00:09:03.799
then these tools are usually starting to
to get to a botty lick in many

85
00:09:03.440 --> 00:09:11.879
DEAVE experience aspects. Interesting. Interesting, So it's very well integrated with disposable

86
00:09:11.960 --> 00:09:18.679
cloud machines that you can just use
for development and then get rid of it.

87
00:09:18.399 --> 00:09:26.440
That's an interesting feature. And who
do you think this feature? Like?

88
00:09:28.720 --> 00:09:35.159
Who do you think is more benefited
by such features? Because I'm trying

89
00:09:35.200 --> 00:09:41.960
to think of a scenario where I
needed something like this, And maybe it's

90
00:09:43.080 --> 00:09:48.159
just not for me, because I
can't think of a scenario where I needed

91
00:09:48.279 --> 00:09:56.279
a solution that didn't require local development. And like I get the concept about

92
00:09:58.559 --> 00:10:03.240
decentralizing that one that one, I
can see how that would fit with my

93
00:10:03.360 --> 00:10:09.840
workflow because I could just have parts
of my system that I break into other

94
00:10:11.320 --> 00:10:16.440
parts I'm not going to call them
other repositories because we're trying to to Also,

95
00:10:18.200 --> 00:10:22.440
as you said, we can also
not work with repositories at all and

96
00:10:22.519 --> 00:10:26.879
still have a way to share this
code with others. So okay, I

97
00:10:26.879 --> 00:10:33.559
could package it up into a way
and then share it with others. Still,

98
00:10:33.559 --> 00:10:43.159
I'm not entirely I'm not entirely seen
how this would be more productive to

99
00:10:43.279 --> 00:10:48.080
me, at least than, for
example, just publishing a package on NPM

100
00:10:48.360 --> 00:10:56.279
and installing from there. Like,
if I really wanted to separate something from

101
00:10:56.279 --> 00:11:01.120
a main repository and share it with
others, my approach would probably this,

102
00:11:01.960 --> 00:11:09.120
but yours might be better. I'm
just I haven't fully understood how that would

103
00:11:09.120 --> 00:11:16.080
be more interesting than just packaging it
up and putting it on NPM, And

104
00:11:16.240 --> 00:11:26.000
also not seeing how in which circumstances
the cloud development we're using temporary machines would

105
00:11:26.080 --> 00:11:33.840
be more interesting than just the regular
local development. Okay, so great question.

106
00:11:35.320 --> 00:11:39.679
So first, maybe something that was
not very clear for my description this

107
00:11:39.799 --> 00:11:46.360
disposable workspace today on your local machine. Okay, so it's just a tempo

108
00:11:46.600 --> 00:11:52.320
for them that you create locally computer
instead of cloning the entire report. We

109
00:11:52.480 --> 00:11:58.679
do plan soon to release like a
cloud workspace, which will give you the

110
00:11:58.720 --> 00:12:03.639
same experience on the cloudoud and and
so so the question so I will split

111
00:12:03.679 --> 00:12:09.639
your question to why should I do
it locally on you on my machine versus

112
00:12:09.679 --> 00:12:13.960
why should I do it on cloud? And what and what cloud UH give

113
00:12:15.039 --> 00:12:18.360
me? In this use case,
I'll start with cloud because I think it's

114
00:12:18.399 --> 00:12:26.600
like shorter and easier to to explain
and and editing on component based on the

115
00:12:26.639 --> 00:12:33.120
cloud is very very good for different
types of persons. First, people who

116
00:12:33.120 --> 00:12:37.480
are not developers but working with developers. For example, if you have a

117
00:12:37.519 --> 00:12:43.120
cloud workspace, and cloud workspace BIT
is managing the entire life cycle. So

118
00:12:43.159 --> 00:12:46.720
BIT is knowing how to compile your
component and also show you a fender version

119
00:12:46.759 --> 00:12:52.120
of your component similar to storybook,
and showing you the test results and everything.

120
00:12:52.440 --> 00:12:56.879
So if you are a designer now
and you can change the CSS and

121
00:12:56.919 --> 00:13:01.960
see the components lendering and then make
a kind of a pull request like we

122
00:13:01.039 --> 00:13:07.000
call it change request right from the
cloud without need to set up anything.

123
00:13:07.480 --> 00:13:11.320
This is now a game changer because
now as a designer with out most of

124
00:13:11.360 --> 00:13:16.000
the way from designer to production,
or if you are a reproduct manager,

125
00:13:16.039 --> 00:13:20.279
and you want to change like a
message, an error message or something like

126
00:13:20.320 --> 00:13:24.279
this, you can do it now
from the cloud without need to do any

127
00:13:24.679 --> 00:13:28.679
local setup as non developer. This
is true also for developers who want to

128
00:13:28.720 --> 00:13:33.039
do small changes in components. So
this is about cloud and this is not

129
00:13:33.159 --> 00:13:39.639
available yet. This is in pogress, but on the local machine. What

130
00:13:39.799 --> 00:13:43.480
important is basically you're right. You
can take something and package it up and

131
00:13:43.840 --> 00:13:48.159
send it to NPM. And Bit
is doing something very similar to this,

132
00:13:48.840 --> 00:13:56.480
but in much better developed developer experience. Because the first let's I will try

133
00:13:56.519 --> 00:14:01.799
to make some kind of farm high
level layout of the main problems or the

134
00:14:01.799 --> 00:14:07.960
main stuff that prevent people from sharing
and reusing more code, and I would

135
00:14:07.960 --> 00:14:13.519
split it. So the first problem
is creation over it. Okay, if

136
00:14:13.559 --> 00:14:18.879
you want more code her, you
need to make more code individual consumerble like

137
00:14:20.039 --> 00:14:26.240
NPM packages. But making a new
NPM packages from repository with a big project

138
00:14:26.759 --> 00:14:31.240
is a big task. Let's say
you want to take your projects and start

139
00:14:31.279 --> 00:14:35.240
splitting it up to many many individual
components, and then you take each one

140
00:14:35.240 --> 00:14:39.200
of them and make a new repository, and then you need to set up

141
00:14:39.600 --> 00:14:43.480
all the tool chain you need to
set up compiler and CI and tester and

142
00:14:43.559 --> 00:14:50.080
linter and make read me and contribution
docs. So in order to do this

143
00:14:50.159 --> 00:14:56.399
in scale, it's just doesn't work. So organizations solve these problems today in

144
00:14:58.240 --> 00:15:05.720
two and two in two ways.
One way is that they're doing it only

145
00:15:05.759 --> 00:15:11.759
for the stuff that are commonly shared. For example, design systems, the

146
00:15:11.960 --> 00:15:16.080
design system in the organization or building
design system, and this is shared in

147
00:15:16.240 --> 00:15:22.120
NPM and everyone users because they know
people will use it. The other kind

148
00:15:22.120 --> 00:15:26.279
of solution people have is to peck
many things together. So the design system

149
00:15:26.600 --> 00:15:31.000
they pack together fifty or one other
components and then they have like a kind

150
00:15:31.000 --> 00:15:35.960
of a util function library, something
like loaded shoranda of the organization, and

151
00:15:37.000 --> 00:15:41.240
this is another one of the components
inside of it. Because making one hundred

152
00:15:41.279 --> 00:15:48.320
repositors for the design system and doing
everything one other time is just not possible.

153
00:15:48.879 --> 00:15:56.320
And this leads to two kind of
conflicts of interest of using this shared

154
00:15:56.360 --> 00:16:03.919
code. For example, if now
your design system is composed from one components,

155
00:16:03.279 --> 00:16:10.519
then I'm as a user, lets
want to use it because few different

156
00:16:10.559 --> 00:16:15.440
problems. The first problem is that
if I only want potion or some components

157
00:16:15.440 --> 00:16:21.720
form your design system and design system
is just an example, okay that it

158
00:16:21.759 --> 00:16:26.399
could be like other kind of library
packages. And by the way, this

159
00:16:26.639 --> 00:16:32.159
talent true only for frounded. When
I see a components in this context or

160
00:16:32.240 --> 00:16:36.000
in the context of FIT, it
can be anything. It can be a

161
00:16:36.159 --> 00:16:38.600
ut function, it can be a
micro service, it can be even an

162
00:16:38.639 --> 00:16:47.000
application, not only fraunded components.
Many of the examples might be one and

163
00:16:47.120 --> 00:16:52.720
related because it's just easier to understand
and the audiences are react people usually,

164
00:16:52.440 --> 00:16:59.200
but it's true for also for deeconds
and all this world. So back to

165
00:16:59.240 --> 00:17:06.200
the problem of this solution is one
that if I only want two components from

166
00:17:06.240 --> 00:17:11.640
your design system, now I'm bringing
the entire design system and my bundle side

167
00:17:11.680 --> 00:17:15.640
and my performance are going to be
much worse. Yes, we do have

168
00:17:15.720 --> 00:17:18.640
three shaking, but it's not perfect. It's about from perfect. So if

169
00:17:18.680 --> 00:17:22.920
I only need a small part of
it, I'm not going to use the

170
00:17:22.960 --> 00:17:29.240
package you published. I'm just going
to build my own copy from your design

171
00:17:29.240 --> 00:17:33.839
system. Another problem is the updating
problem. Let's say you update the button

172
00:17:33.880 --> 00:17:38.920
components now as a user. If
now I need to update the button,

173
00:17:40.000 --> 00:17:42.119
I need to update the entire design
system, which will I'm now updating one

174
00:17:42.160 --> 00:17:45.599
our components, and I have no
idea what is going to happen to my

175
00:17:45.680 --> 00:17:52.319
product when I update one other components
at once. So because I know this

176
00:17:52.440 --> 00:17:55.720
ahead of time that every time I'm
using the design system I will need to

177
00:17:55.759 --> 00:17:59.960
update it once, I less likely
want to use it and at less likely

178
00:18:00.200 --> 00:18:04.759
to update it when you do changes
unless someone forces me. Let's say the

179
00:18:04.799 --> 00:18:10.039
head of design forced me to update
the design SISTE version of head of security

180
00:18:10.400 --> 00:18:14.279
forced me because there was like a
securge issue that was update. So someone

181
00:18:14.400 --> 00:18:18.640
pushing me from outside to update right
now. On the other end, if

182
00:18:18.680 --> 00:18:23.240
these are individual components, then I'm
taking only what I need. Then this

183
00:18:23.480 --> 00:18:29.960
problem does not exist from the first
place. So the first very big issue

184
00:18:30.000 --> 00:18:37.279
is to make it very easy to
make many components individually available and every component,

185
00:18:37.319 --> 00:18:42.079
by the way, every component you
expert to be it is available as

186
00:18:42.200 --> 00:18:48.480
regular NPM package and you can install
it like any other package using your favorite

187
00:18:48.480 --> 00:18:52.960
package manager PMPM and PM down whatever. So the first thing is like to

188
00:18:53.000 --> 00:19:00.960
automate this entire process. Another big
problem on like the creation over it is,

189
00:19:02.240 --> 00:19:07.519
for example, maintaining dependencies and package
Jason. Okay, so once you

190
00:19:07.599 --> 00:19:11.640
start splitting all of it, you
need to manage one other package Jason and

191
00:19:11.680 --> 00:19:15.440
dependencies. This should be a def
dependency here, it's a random dependency here,

192
00:19:15.680 --> 00:19:18.880
and to install it, I need
to manage all the versions. While

193
00:19:19.160 --> 00:19:22.720
one of the for example, one
of the problems we are dealing with,

194
00:19:23.160 --> 00:19:29.039
is how to make it easy in
your own project, even an existing project,

195
00:19:29.359 --> 00:19:33.680
to take small pieces, small components
out of it at an NPM package

196
00:19:33.880 --> 00:19:40.359
without need to set anything, and
we automate the entire dependency management, so

197
00:19:40.400 --> 00:19:45.200
we know to static cot analysis your
source code and add dependencies, automatically,

198
00:19:45.359 --> 00:19:49.720
manage the version, automatically, even
manage if it's a deaf dependency or one

199
00:19:49.720 --> 00:19:56.440
time dependency based on if you use
it from a spec file or from your

200
00:19:56.799 --> 00:20:02.480
regular file of the component, for
example. So this is one thing.

201
00:20:02.880 --> 00:20:10.240
Another big problem is that organizations tend
to share the code that they know for

202
00:20:10.359 --> 00:20:15.160
sure that will be used, like
design systems. However, because of this

203
00:20:15.680 --> 00:20:21.920
big overread of sharing and creation,
they don't try to share other code,

204
00:20:22.359 --> 00:20:26.480
which is in real life, once
it's tried, is very very usable as

205
00:20:26.519 --> 00:20:33.279
well. So many product teams can
benefit from other product team components. But

206
00:20:33.599 --> 00:20:41.680
these other product teams just don't share
this code because they they don't do they

207
00:20:41.680 --> 00:20:47.119
don't want to do this effort of
sharing the code of doing all this manual

208
00:20:47.200 --> 00:20:53.000
and tedious process of like started out, makeeeople, make the docs, make

209
00:20:53.079 --> 00:21:02.720
everything set up so you get eventually
much let's call chilled in your organization,

210
00:21:03.519 --> 00:21:08.079
then what you can get. Okay, that that does make sense. It's

211
00:21:08.160 --> 00:21:15.160
so much more powerful than I had
understood at first. So it's really amazing.

212
00:21:18.039 --> 00:21:19.920
Nice. How long have you been
working on this? By the way,

213
00:21:21.000 --> 00:21:23.480
I imagine that you were there from
the start, right or probably I'm

214
00:21:23.559 --> 00:21:30.559
not. I wasn't from the from
the field day. I kind of joined

215
00:21:30.920 --> 00:21:34.720
once they finished to do like once
the founder was finished, to do that

216
00:21:36.160 --> 00:21:41.559
the pivots of any any startup.
So it was one of the Fields employees,

217
00:21:42.279 --> 00:21:48.839
and I joined almost seven years ago. Seven years Yeah. Yeah,

218
00:21:48.960 --> 00:21:53.960
this is a very big and complex
product. Yeah. By the way,

219
00:21:55.039 --> 00:21:59.200
something that I didn't mention, which
is related like to your questions that I

220
00:21:59.279 --> 00:22:04.279
forget to read, is about this
disposable workspace. So like I said that

221
00:22:04.480 --> 00:22:14.640
bit, it is not only a
technical solution. It's about philosophy and methodology.

222
00:22:14.799 --> 00:22:18.839
Like the philosophy is basically you need
to split code and shall more code.

223
00:22:18.440 --> 00:22:23.039
And then in the methodology, one
of the one of the stuff is

224
00:22:23.440 --> 00:22:32.160
to help the organization do the mind
shift of being more collaborated. So,

225
00:22:32.200 --> 00:22:34.960
for example, when you build a
component in the context of a RIPO,

226
00:22:36.440 --> 00:22:41.680
in the context of projects, you
tend to make it more bounded to this

227
00:22:41.240 --> 00:22:47.039
context and this project. Okay,
because you build it for yourself inside this

228
00:22:47.200 --> 00:22:55.759
context. But if you think about
about the component as the let's say the

229
00:22:55.920 --> 00:23:03.880
core entity of you are in the
product or an R and D team and

230
00:23:03.960 --> 00:23:08.680
not the project or the application as
the cops. So most of the organizations

231
00:23:08.799 --> 00:23:15.720
are building their R and D structure
around applications. They build team around application,

232
00:23:17.279 --> 00:23:22.160
they do CICD for application, they
do testing in the application level.

233
00:23:23.279 --> 00:23:29.839
And the components. Today everyone builds
components, like everyone that uses any framework,

234
00:23:29.920 --> 00:23:33.599
react, you under up whatever,
they build components, but they build

235
00:23:33.640 --> 00:23:40.000
components to serve the clunt application.
While what we're trying to do in a

236
00:23:40.039 --> 00:23:45.400
BIT is to shifting it so the
components are the main thing. Then the

237
00:23:45.440 --> 00:23:52.559
application is just a composition of different
components. So when you build the components,

238
00:23:52.640 --> 00:23:55.279
let's say you have a feature,
okay, you need to build a

239
00:23:55.279 --> 00:23:57.960
future let's take a real example.
You need to make a new header for

240
00:23:59.079 --> 00:24:04.079
your website. Okay, everyone did
it in the past, and when you

241
00:24:04.119 --> 00:24:10.720
do, when you do this inside
your project, there's more likely that this

242
00:24:10.839 --> 00:24:15.400
header is going to be coupled in
different ways to the application. While if

243
00:24:15.400 --> 00:24:21.200
you think about header as a feature, what how it looks like if you

244
00:24:21.240 --> 00:24:25.160
try to think about like the definition
of this feature, okay, and the

245
00:24:25.200 --> 00:24:30.319
way we see the definition of a
feature is very simple. A feature is

246
00:24:30.359 --> 00:24:34.319
a set of components. A components. Some of them need to be built

247
00:24:34.359 --> 00:24:40.200
from scratch, they don't exist.
Some of them need to be used because

248
00:24:40.240 --> 00:24:41.640
we already built them and we need
to use it. And some of them

249
00:24:41.680 --> 00:24:45.799
need to be used and modified because
we need I don't know new APIs from

250
00:24:45.839 --> 00:24:52.039
there. So if you need now, if now this is the definition of

251
00:24:52.079 --> 00:24:56.559
the header feature, you make a
new folder. This folder, it's an

252
00:24:56.559 --> 00:25:02.200
empty folder, okay, And on
your local machine you do beat create header

253
00:25:02.559 --> 00:25:07.559
create you and you react components from
a template and you start implementing the heather

254
00:25:07.880 --> 00:25:11.640
and then you start to install components
like NPM install. You do it with

255
00:25:11.720 --> 00:25:17.279
bit but it's basically behind the scene, just PMPM install mostly then you do

256
00:25:17.640 --> 00:25:22.799
install a logo, and you install
a search box, and you install menu

257
00:25:22.039 --> 00:25:26.839
whatever, and then you need to
change something because you need to make the

258
00:25:26.880 --> 00:25:33.240
search box, I don't know,
collapse whatever. Then you just import the

259
00:25:33.319 --> 00:25:37.400
search box. You add this new
feature to the search box, and then

260
00:25:37.000 --> 00:25:41.960
once you finish the head, you
build it in isolation. Once you build

261
00:25:42.000 --> 00:25:47.079
an isolation, it's much more likely
to be reduced a bit easy. And

262
00:25:47.119 --> 00:25:51.799
then once you finish, you might
import the application itself, and you do

263
00:25:52.079 --> 00:25:56.480
for integration purposes, so you bring
the application at the end, not at

264
00:25:56.519 --> 00:26:02.799
the beginning. And this only this
alone make a lot of changes of the

265
00:26:02.880 --> 00:26:07.680
reusability. And this is like it's
like a fake. It's like a fake

266
00:26:07.799 --> 00:26:10.920
change. Okay, I tell a
few mentality. You can fake, you

267
00:26:10.920 --> 00:26:14.160
can pose yourself to do it,
but once you have the tours and you

268
00:26:14.200 --> 00:26:18.640
can do it for real, it's
it just happens much better. Hey,

269
00:26:18.680 --> 00:26:22.839
there, this is Charles Maxwood.
I'm excited because I wanted to let you

270
00:26:22.920 --> 00:26:26.039
know about this thing that I pulled
together that I had just I've been dying

271
00:26:26.079 --> 00:26:30.920
to have this for years and I
never felt like I could. And then

272
00:26:30.960 --> 00:26:33.119
I just realized that there's no reason
why I can't. So I'm putting together

273
00:26:33.119 --> 00:26:37.039
a book club and we're going to
read development focused books, career books,

274
00:26:37.160 --> 00:26:41.119
you know, technical books, whatever. The first book that we're going to

275
00:26:41.200 --> 00:26:45.680
do is going to be Clean Architecture
by Uncle Bob Martin. If you're not

276
00:26:45.720 --> 00:26:48.279
familiar with clean code or some of
the other stuff that Bob has done,

277
00:26:48.480 --> 00:26:52.119
check that out. I've also talked
to him on the Clean Coders podcast,

278
00:26:52.160 --> 00:26:55.359
which is on Top End Devs.
But yeah, we're gonna get on.

279
00:26:55.440 --> 00:26:57.039
He's going to show up to some
of our meetings. And what I'm thinking

280
00:26:57.079 --> 00:27:02.319
is we'll probably have like five or
six people part of the conversation along with

281
00:27:02.359 --> 00:27:06.559
Bob and I at the same time, and we'll just so somebody can come

282
00:27:06.599 --> 00:27:10.480
on, they can ask their question, and then we'll just rotate people through,

283
00:27:10.519 --> 00:27:14.240
so we'll mute one person, unmute
another person when it's their turn to

284
00:27:14.279 --> 00:27:17.960
come on and be part of the
discussion. So we'll do that for like

285
00:27:18.000 --> 00:27:19.160
an hour hour and a half.
And then the other part of it that

286
00:27:19.200 --> 00:27:23.880
I'm putting together is just kind of
a meet and greet gather area on gather

287
00:27:25.000 --> 00:27:29.880
Town, and so after the meetup
and the call, we we'll do as

288
00:27:29.920 --> 00:27:33.039
we'll all go over to gather Town
and you can just log in, walk

289
00:27:33.119 --> 00:27:36.359
up to a group and have a
conversation, and that way we can all

290
00:27:36.440 --> 00:27:40.599
kind of get to know each other
and make friends and get to know people

291
00:27:40.640 --> 00:27:42.160
across the world. One thing that
I'm finding is that, yeah, the

292
00:27:42.200 --> 00:27:45.880
meetups are starting to come back,
but a lot of people don't have the

293
00:27:45.920 --> 00:27:48.759
opportunity to go to a meetup.
And I really want to meet you guys

294
00:27:48.839 --> 00:27:51.319
and talk to you. So we're
gonna put all that together. We'll all

295
00:27:51.319 --> 00:27:53.000
be part of that book club.
You can go to topendevs dot com slash

296
00:27:53.039 --> 00:27:56.119
book Club to be part of it, and I'm looking forward to seeing you

297
00:27:56.160 --> 00:28:00.599
there. The first book club meeting
will be in December, the beginning of

298
00:28:00.680 --> 00:28:06.079
December. We're starting the first week
of December, and you'll also be part

299
00:28:06.079 --> 00:28:08.880
of the conversation about which book we
do next. I have one in mind,

300
00:28:10.160 --> 00:28:11.680
but I want to see where everybody's
at, So there you go.

301
00:28:14.640 --> 00:28:21.279
I'm just thinking about how this could
have said so much of my time if

302
00:28:21.319 --> 00:28:26.160
I knew about this feature earlier.
It's crazy that I'm just hearing about it

303
00:28:26.200 --> 00:28:32.039
now and it exists for well,
you've been working on it for seven years,

304
00:28:32.039 --> 00:28:37.160
but for how long has it been
like stable and open for public consumption.

305
00:28:38.599 --> 00:28:48.319
So it is available for around let's
say three years ago, we did

306
00:28:48.359 --> 00:28:55.880
like a major major version and people
will really start using it at scale.

307
00:28:56.279 --> 00:29:03.759
And we did another big changes like
about a year ago, which which helps

308
00:29:03.119 --> 00:29:11.200
many organizations start using like sometimes ago. We we we make a lot of

309
00:29:11.440 --> 00:29:18.759
features around the cloud to make it
really works good not only for individuals but

310
00:29:18.799 --> 00:29:25.799
also for big organizations. And we
can discuss some of I can I can

311
00:29:25.599 --> 00:29:30.680
then take some example of give some
example of what it means. So for

312
00:29:30.759 --> 00:29:40.079
example, let's let's take another another
big problem in sharing the reusability. You

313
00:29:40.079 --> 00:29:45.559
you start developing, you the feature, and and you use the design system

314
00:29:47.000 --> 00:29:52.359
okay for the menu, and now
you need this menu to be uh this

315
00:29:52.559 --> 00:29:56.839
these menu items, like the buttons
in the menu, you need them to

316
00:29:56.920 --> 00:30:02.839
be rounded and not square, okay
for example, but this feature does not

317
00:30:02.960 --> 00:30:11.359
exist on the on the design system
button now in in the real world today,

318
00:30:11.920 --> 00:30:17.319
once you get to something like this, you need to choose your way.

319
00:30:17.759 --> 00:30:22.640
One way is to try to push
it upstream, like to the design

320
00:30:22.680 --> 00:30:27.359
system. Okay, so you need
now to ford the design system set up

321
00:30:27.400 --> 00:30:30.920
everything, rite, contribution dogs,
write, set up dogs, read,

322
00:30:32.119 --> 00:30:36.680
read set up dogs, and set
up everything to make this change. And

323
00:30:36.720 --> 00:30:38.359
then you need to do this change
and you need to make a pull it.

324
00:30:38.440 --> 00:30:42.079
Weest wait for the review, wait
for them to merge it, and

325
00:30:42.119 --> 00:30:45.480
then wait for them to publish it, to publish a new version. And

326
00:30:45.559 --> 00:30:53.119
this is one a very annoying process
for you as someone is not part of

327
00:30:53.119 --> 00:30:59.200
the design system team. And secondly, this takes a long time. What

328
00:30:59.799 --> 00:31:04.279
I you're doing in the meantime until
it's published with a new version. Right,

329
00:31:04.359 --> 00:31:08.480
you you have a product in pushing
you to make something to production and

330
00:31:08.599 --> 00:31:14.079
they don't care that the design system
is working slow or the design system have

331
00:31:14.200 --> 00:31:18.519
their own priorities which are different than
your priorities. And the other way you

332
00:31:18.559 --> 00:31:22.920
can do is, Okay, I
need a change, they don't do it.

333
00:31:22.039 --> 00:31:29.319
I will just copypaste the menu button
and I will do any change in

334
00:31:29.400 --> 00:31:34.559
want and I will detach from the
design system button. Which this is but

335
00:31:34.720 --> 00:31:41.200
the way what most organizations do in
many many cases they detach uh. And

336
00:31:41.319 --> 00:31:48.799
this means once that you have now
a problem of consistency, right because they

337
00:31:48.839 --> 00:31:52.440
have the design tomorrow and you don't
have this update, and it means that

338
00:31:52.599 --> 00:31:56.240
if they have a bag, they
need they fix it, and now you

339
00:31:56.359 --> 00:32:00.079
need to fix it as well,
because they don't connect anymore. And the

340
00:32:00.200 --> 00:32:02.720
duplications are going and going all the
time. So you're not the only one

341
00:32:02.720 --> 00:32:08.279
that copied is battled. There many
other things that copy is batted and and

342
00:32:08.440 --> 00:32:14.759
everyone now needs to fix this bag
and to rely the design. If there

343
00:32:14.799 --> 00:32:19.359
is a security hall, then it
needs to be fixed ten times. So

344
00:32:19.400 --> 00:32:22.839
it's very costly. On the other
end, it gives you kind of the

345
00:32:22.920 --> 00:32:30.160
edge of getting to production faster.
What we build in order to kind of

346
00:32:30.079 --> 00:32:36.599
handle this entire let's say cycle.
Okay, this this happened every day for

347
00:32:36.759 --> 00:32:40.559
every company, for every developer.
Okay, it's not something that people don't

348
00:32:40.599 --> 00:32:45.559
know. But we came up with
a different approach to solve this, and

349
00:32:45.640 --> 00:32:51.480
we build a concept. We called
it a lane. A lane you can

350
00:32:51.480 --> 00:33:00.240
think about lane as a similar term
for git brunch okay, but not but

351
00:33:00.559 --> 00:33:05.880
like a multi report git brench okay, because if you think about it,

352
00:33:06.039 --> 00:33:10.640
each component is kind of like a
mini repository. You can it's it has

353
00:33:10.680 --> 00:33:15.599
its own version in and you can
import it to any workspace, kind of

354
00:33:15.720 --> 00:33:21.400
clone it to any workspace and change
from any workspace. So LANE is when

355
00:33:21.400 --> 00:33:28.400
you aggregate many changes across many components. And these components might be you components

356
00:33:28.559 --> 00:33:31.599
that belong to your team, and
there might be someone else components like the

357
00:33:31.640 --> 00:33:38.920
design team component, the security team
components, whatever team. So you try,

358
00:33:39.039 --> 00:33:43.359
You start to build a features,
and you build new components, and

359
00:33:43.440 --> 00:33:47.599
you change components from other people,
and then eventually you make a change request.

360
00:33:47.799 --> 00:33:54.000
A change request is very similar to
pull request in guitab, but there

361
00:33:54.039 --> 00:34:01.920
are a few different very important the
distinction. The first is that you change

362
00:34:01.920 --> 00:34:08.679
components from different teams. Okay,
so now you do a review one review

363
00:34:09.079 --> 00:34:13.719
okay, like an atomic review for
you lane, because your lane is like

364
00:34:13.960 --> 00:34:20.079
one entity for many components, and
this review should be done by your pills

365
00:34:20.119 --> 00:34:23.519
from your team and by people from
other teams that you change the code okay,

366
00:34:23.559 --> 00:34:28.840
you don't have permission to publish or
push code to the design system team,

367
00:34:29.159 --> 00:34:32.320
so someone from the design system team
need to improve it, and and

368
00:34:32.960 --> 00:34:40.039
so you do like a like realistic
review one for many components, second for

369
00:34:40.239 --> 00:34:49.840
different teams. Third is that you
do review for different roles in the organization.

370
00:34:50.280 --> 00:34:54.800
Because bit is similar to get in
a way because it's it's a version

371
00:34:54.960 --> 00:35:02.760
system. But our entity that we've
version is a component and the component is

372
00:35:04.119 --> 00:35:08.840
a much more complicated entity than a
file. So we version from each component.

373
00:35:09.320 --> 00:35:14.519
Each version contains not only the source
code, it contains only also the

374
00:35:14.639 --> 00:35:19.800
artifacts for example, the bundle of
the component, the package, top of

375
00:35:19.800 --> 00:35:25.480
the component, the compiled fives and
it contains configuration for this component. And

376
00:35:25.559 --> 00:35:30.480
this is something else that we should
talk about, like how you compile,

377
00:35:30.519 --> 00:35:32.800
how to compile this component, how
to test this component, how to link

378
00:35:32.840 --> 00:35:37.960
the component, so different configuration of
the components. This is part of the

379
00:35:37.000 --> 00:35:43.519
component version. And also it contains
like the dependencies. So when you do

380
00:35:43.639 --> 00:35:50.000
review, different types of people from
different roles doing review. So you have

381
00:35:50.079 --> 00:35:53.079
review code review from the designer,
from the developer, and you can also

382
00:35:53.079 --> 00:36:00.599
see the rendering compared rendering side by
side, think about like storybooks by side

383
00:36:00.800 --> 00:36:05.280
that the designer can add comments on
the design and then you have like an

384
00:36:05.360 --> 00:36:12.920
architect that comment on changes on dependencies. So and the product that can uh

385
00:36:13.000 --> 00:36:16.239
that can do a review, and
technical writers that can review the do commentation

386
00:36:16.360 --> 00:36:22.320
of the component. Because it's also
part of these comparison. So we compare

387
00:36:22.639 --> 00:36:28.480
source code, compare rendering, compare
dogs, compare test coverage, compare test

388
00:36:28.519 --> 00:36:32.519
results, compare everything. So different
people are doing the review, and the

389
00:36:32.599 --> 00:36:38.400
review is also on different types of
changes, because when you do change components,

390
00:36:38.400 --> 00:36:43.679
you only you don't only change code. Sometimes you change you change dependency,

391
00:36:44.320 --> 00:36:47.480
sometimes you change the configuration. Now
this was used in types four,

392
00:36:47.559 --> 00:36:52.719
now it's uses types to five.
Before it was using linting with these rules.

393
00:36:52.760 --> 00:36:57.480
Now it's linding with different rules.
So you do many kind of changes,

394
00:36:57.559 --> 00:37:01.400
and then you do a full review
on all these aspects. And then

395
00:37:01.440 --> 00:37:08.840
once you merge the lane, then
these components are shipped across the entire change

396
00:37:09.239 --> 00:37:15.840
and an entire organization. So you
can now have an atomic atomic review and

397
00:37:15.840 --> 00:37:22.480
atomic merge for your entire feature.
And then the next step of it is

398
00:37:23.679 --> 00:37:30.840
kind of propagating, propagating the changes. Okay, Let's say you are a

399
00:37:30.880 --> 00:37:36.079
design system team and you make a
new version for the button. Okay,

400
00:37:36.800 --> 00:37:43.239
now you now, now what you
want is to make this button ship it

401
00:37:43.320 --> 00:37:49.320
in production as soon as possible.
But but other teams need to adopt your

402
00:37:49.559 --> 00:37:55.719
button. It takes time. So
what we built is is a new type

403
00:37:55.760 --> 00:38:04.119
of CI. Okay, all organism
and all cis today are built around applications

404
00:38:04.159 --> 00:38:07.719
and projects, which mean you the
CI is first doing a Git clone for

405
00:38:07.760 --> 00:38:15.280
the entire project and then start doing
something on the project level. But we

406
00:38:15.320 --> 00:38:19.760
build a component level CI, which
means once you change button, we will

407
00:38:19.800 --> 00:38:24.119
test button alone, and then we
check the card that users button, and

408
00:38:24.199 --> 00:38:29.079
then we change. We checked the
grid which has a lot of cards,

409
00:38:29.239 --> 00:38:34.199
and then we check the page which
uses this grid. So we kind of

410
00:38:34.320 --> 00:38:37.199
building a graph because bit is like
we said, you know, a build

411
00:38:37.519 --> 00:38:42.679
is a weal for the entire graph
of your organization components. So we build

412
00:38:42.679 --> 00:38:50.519
a graph and we start propagating change
from the smallest component or the the most

413
00:38:50.559 --> 00:38:58.000
nested component up to the entire organization, and we can now filst We get

414
00:38:58.000 --> 00:39:07.000
a very very fast CI. Why
because one because it's parallelized in the component

415
00:39:07.119 --> 00:39:12.039
level, so each component gets its
own container. Okay. Secondly, we

416
00:39:12.159 --> 00:39:15.559
only check and we only run what
is affected from these changes. Okay,

417
00:39:15.559 --> 00:39:20.920
and and the like the seis of
this draft might be a few components.

418
00:39:20.960 --> 00:39:25.039
Okay, let's say your name might
you may you might change five components at

419
00:39:25.079 --> 00:39:30.400
once, So we only check what
is affected by these seeders, and we

420
00:39:30.559 --> 00:39:35.760
parallelize it to the maximum. And
now also for the first time, you

421
00:39:35.800 --> 00:39:44.039
can see visually how your components changes
will affect people or components from other teams

422
00:39:44.400 --> 00:39:47.719
that you don't even aware that you're
using, that they are using your code

423
00:39:49.039 --> 00:39:52.519
in the visual ways. So you
can see that the button that you change

424
00:39:52.920 --> 00:39:58.320
is breaking the about page that maintained
of course by like a product team.

425
00:39:58.760 --> 00:40:01.159
And now you can talk about you
can see it in one place and talk

426
00:40:01.199 --> 00:40:07.320
about why a pattern change break the
depout page. Okay, and you can

427
00:40:07.320 --> 00:40:10.800
communicate about this change. Maybe you
did the breaking change in the API.

428
00:40:12.320 --> 00:40:16.239
Maybe they use an internal API from
the pattern, but they shouldn't use that's

429
00:40:16.239 --> 00:40:21.960
why they break. But now even
before you publish the patent okay, and

430
00:40:21.960 --> 00:40:25.119
then today world, what happens usually
is the design system published the paton or

431
00:40:25.159 --> 00:40:30.800
the design system and then two months
later some team is updating it and then

432
00:40:30.880 --> 00:40:36.480
this is that it's breaking the other
team and they didn't know about it.

433
00:40:36.559 --> 00:40:42.199
You can take some now even before
the merge, you know that the paton

434
00:40:42.239 --> 00:40:45.920
change will affect someone else in a
bad way or in a good way.

435
00:40:47.079 --> 00:40:53.599
So this is another important process of
it all. This new feature like the

436
00:40:53.679 --> 00:41:00.039
CI and the product review and the
code review or change request review land review

437
00:41:00.280 --> 00:41:07.760
available around they so this makes a
big change in the market of big organizations

438
00:41:07.760 --> 00:41:15.239
that starts adopting it. Understood,
understood. So we we spoke a lot.

439
00:41:15.400 --> 00:41:20.400
Unfortunately, there's just so much more
than that we could talk about.

440
00:41:21.320 --> 00:41:27.159
Uh. You mentioned before we started
to show that you could speak about this

441
00:41:27.199 --> 00:41:30.079
for three hours, and now I
can see that this was very serious.

442
00:41:30.159 --> 00:41:35.679
Like I think three hours is is
not that long. Actually, I think

443
00:41:35.719 --> 00:41:39.159
we would need a lot more than
that. There's a lot of interesting things

444
00:41:39.199 --> 00:41:45.480
to talk about, uh, to
talk about bits. So but unfortunately we're

445
00:41:45.519 --> 00:41:50.679
gonna have to start wrapping up this
episode just so that it doesn't take super

446
00:41:50.719 --> 00:41:57.159
long. But before we start wrapping
up, is there anything that we haven't

447
00:41:57.519 --> 00:42:02.559
talked about yet? And you think
that we definitely need to talk about this

448
00:42:02.760 --> 00:42:12.880
before finishing this episode. I think
that's maybe kind of one more important feature

449
00:42:13.280 --> 00:42:19.360
or concept that is that is interesting
just to give a glimpse, and this

450
00:42:19.559 --> 00:42:27.880
called the component environment. Component environment
is basically a component, okay, so

451
00:42:27.920 --> 00:42:32.480
we kind of have a special kind
of components basically implement some kind of interface,

452
00:42:32.840 --> 00:42:38.519
which are components that manage other components
life cycle Okay, it's a bit

453
00:42:38.599 --> 00:42:44.199
complicated. I would try to simplify
it in a second, in two minutes.

454
00:42:44.599 --> 00:42:49.239
So let's think about created act up
okay, and let's think if you

455
00:42:49.280 --> 00:42:54.239
could take created act up and then
put it into a component that you can

456
00:42:54.280 --> 00:43:00.039
extend or modify in the organization level, in the group level, in the

457
00:43:00.039 --> 00:43:06.079
department level, in the team level, and you're versioning it and you can

458
00:43:06.119 --> 00:43:14.239
customize it. Okay. So basically
you can create this kind of component environment

459
00:43:14.360 --> 00:43:19.920
components in your organization for different types
of component. Let's say you say this

460
00:43:20.000 --> 00:43:24.280
is my environment for React components.
It contains stuff like how to compile React

461
00:43:24.280 --> 00:43:30.440
components, which types of configuration or
bublic configuration, how to test React components,

462
00:43:30.440 --> 00:43:37.000
which tool you are used just with
something else, linking configuration, retail

463
00:43:37.000 --> 00:43:44.239
configuration, bonding configuration, whatever,
and then and it also contained templates,

464
00:43:44.320 --> 00:43:49.639
so the environment is also registering templates. So I have templates for Reactive I

465
00:43:49.760 --> 00:43:53.199
components, a template for React cook
a template for the reactiplication for example.

466
00:43:53.559 --> 00:43:57.679
And then you have like a node
component, and then you have I don't

467
00:43:57.679 --> 00:44:01.559
know, an MDX component type,
different types of components. Then when you

468
00:44:01.599 --> 00:44:07.920
create a new component, you just
a touch we just mentioned which type of

469
00:44:07.960 --> 00:44:12.719
component it is, and then all
this configuration and everything is like, uh

470
00:44:13.320 --> 00:44:17.239
like hidden from you and the platform
of the organization. You manage this environment,

471
00:44:17.679 --> 00:44:22.360
but this gives you like one unified
experience. So in one workspace,

472
00:44:22.400 --> 00:44:27.519
you might have React components, Angular
components, Note components and the ex component

473
00:44:27.599 --> 00:44:31.480
in the same place and you just
take bit bait compile all components. Okay,

474
00:44:31.480 --> 00:44:35.480
and you don't need to know how
to compile components. If you input

475
00:44:35.519 --> 00:44:38.800
a component from the cloud, you
can just a bit to compile it to

476
00:44:38.920 --> 00:44:45.280
lind it according to the author original
standards. And even if you use different

477
00:44:45.320 --> 00:44:47.599
tools. So some components in your
works this might use such steps, some

478
00:44:47.719 --> 00:44:53.159
long, some use just some use
tests and you get one unified output of

479
00:44:53.280 --> 00:45:01.320
everything that by bit applying each environment
on each component and aggregate all the results

480
00:45:01.320 --> 00:45:05.119
together so you don't need to mess
with it. You don't need to do

481
00:45:05.159 --> 00:45:10.119
anything. Uh And this increase a
lot the way of creating new components that

482
00:45:10.159 --> 00:45:15.480
are easily show a bit and we
use a bel because you don't need to

483
00:45:15.519 --> 00:45:21.559
do anything related to configuration. Did
that? There's just so much there's just

484
00:45:21.599 --> 00:45:27.239
so much to cover. Yeah,
Chris, you good like do you want

485
00:45:27.280 --> 00:45:30.159
to ask anything before you start wrapping
up? Yeah? I did just two

486
00:45:30.239 --> 00:45:36.159
quick questions. So the first one
I noticed, like I'm on the homepage

487
00:45:36.199 --> 00:45:40.199
here and you can learn the various
ways there's there's no and angular and view

488
00:45:40.199 --> 00:45:45.039
and react. Are you guys interested
or is it in the pipeline because I

489
00:45:45.039 --> 00:45:50.920
know a lot of people they'll they'll
of course do their front end and JavaScript,

490
00:45:51.079 --> 00:45:53.639
but the back end they'll do something
like go laying or c sharp or

491
00:45:53.639 --> 00:45:58.880
something like that. Is there any
is that in the planning to somehow support

492
00:45:59.480 --> 00:46:04.360
I mean even like some fancy who
knows some sort of business logic function in

493
00:46:04.400 --> 00:46:07.000
the back end that's written in some
other like a non JavaScript language. Is

494
00:46:07.000 --> 00:46:12.320
there anything like that? So basically, most of it, most of the

495
00:46:12.360 --> 00:46:15.559
technology we built, we build it
in a way that is language agnostic.

496
00:46:15.719 --> 00:46:21.519
Most of it, most of the
concept are not bounded to the JavaScript or

497
00:46:21.559 --> 00:46:27.719
web world. However, there our
SUN features like dependency management and installation and

498
00:46:28.280 --> 00:46:34.280
staticod analysis and passing, which is
of course our language specific. We do

499
00:46:34.360 --> 00:46:38.079
plan to support more languages in the
future, but we not there yet.

500
00:46:38.119 --> 00:46:43.760
We don't have any even not even
a rough time on when we're going to

501
00:46:43.800 --> 00:46:47.280
start working on it. Cool,
awesome, and then the other thing.

502
00:46:47.320 --> 00:46:51.880
This goes way back to the beginning
of what you mentioned. You get some

503
00:46:52.199 --> 00:46:57.280
I think you mentioned you can get
analytics or logging for your components and things

504
00:46:57.320 --> 00:47:00.039
like that. Is that configurable or
like, for example, if I have

505
00:47:00.199 --> 00:47:04.880
just like a button, I don't
think I need you know, some generic

506
00:47:04.880 --> 00:47:07.880
button, I don't need logs or
something like that. But like I don't

507
00:47:07.880 --> 00:47:12.599
know some sort of checkout component there, I want some analytics and logs.

508
00:47:12.639 --> 00:47:19.719
How how does that look? So
basically, today the entire analytics feature is

509
00:47:20.079 --> 00:47:23.079
pretty new, and we are building
all the time new even just before the

510
00:47:23.119 --> 00:47:30.599
meeting, we build new new analytics
around measuring collaboration and use because in today

511
00:47:30.880 --> 00:47:36.119
you don't even know how much to
collaborate or share. Basically it's usually kind

512
00:47:36.119 --> 00:47:43.639
of near to zero. But for
example we build for we monitor for which

513
00:47:43.679 --> 00:47:47.159
component, how much dependency is,
maybe how much impact it is, like

514
00:47:47.239 --> 00:47:54.360
kind of recursive recursive usage of it, and then we aggregate this in the

515
00:47:54.400 --> 00:48:00.079
component level, in the scope level. It's like a group of components in

516
00:48:00.079 --> 00:48:02.400
in the business domain, in the
scope level, in the organization level.

517
00:48:02.800 --> 00:48:08.480
So we add all the time different
way of measuring the effort you put.

518
00:48:08.519 --> 00:48:12.719
So you make a component, how
much value you get from it, how

519
00:48:12.800 --> 00:48:15.000
much? How many people are using
it? Are they using an up to

520
00:48:15.079 --> 00:48:20.079
date version? How many people are
using an old version of this component?

521
00:48:20.440 --> 00:48:23.719
How many people using two versions of
this component in the same three but in

522
00:48:23.800 --> 00:48:30.679
different versions, which means kind of
in consistency and balanceize problems. So and

523
00:48:30.760 --> 00:48:32.840
we build different way of analytics all
the time. You don't need to do

524
00:48:32.920 --> 00:48:38.679
anything to get this analytics. We
we've analyzed the graph, we analyze the

525
00:48:38.840 --> 00:48:43.199
user to analyze the source code all
the time, and we just give you

526
00:48:43.239 --> 00:48:49.760
this. It's part of like the
cloud of of course, cool, very

527
00:48:49.880 --> 00:48:55.280
very cool, very interesting stuff.
Thanks nice. Have you ever wished that

528
00:48:55.320 --> 00:48:59.280
you had a group of people that
were just as passionate about writing code as

529
00:48:59.320 --> 00:49:01.199
you are? I know I did. I did that for most of my

530
00:49:01.280 --> 00:49:05.320
career. I'd go to the meetups, I try and create other opportunities,

531
00:49:05.360 --> 00:49:07.440
and it was just really hard,
right the meetups. I got some of

532
00:49:07.440 --> 00:49:10.239
that, but they were only like
once or twice a month, and it

533
00:49:10.320 --> 00:49:14.480
was just really hard to find that
group of people that I connected with and

534
00:49:14.880 --> 00:49:17.840
really wanted to talk about code a
lot, Right, I mean, I

535
00:49:17.960 --> 00:49:22.880
love writing code. I think it's
the best, and so I've decided to

536
00:49:22.920 --> 00:49:28.440
create this community and create a worldwide
community that we can all jump in and

537
00:49:28.440 --> 00:49:30.840
do it. So we're going to
have two workshops every week. One of

538
00:49:30.880 --> 00:49:34.760
those or two of those every month
are going to be Q and A calls

539
00:49:34.840 --> 00:49:37.880
right where you can get on you
can ask me or me and another expert

540
00:49:37.000 --> 00:49:40.400
questions. The rest of them are
going to be focused on different aspects of

541
00:49:40.519 --> 00:49:45.599
career or programming or things like that. Right, So it'll go anywhere from

542
00:49:45.599 --> 00:49:50.360
like deployments and containers all the way
up to managing your four oh one K

543
00:49:50.519 --> 00:49:53.800
and negotiating your benefits package. Well, we'll cover all of it, okay.

544
00:49:54.239 --> 00:49:59.239
And then we're also going to have
meetups every month for your particular technology

545
00:49:59.280 --> 00:50:01.800
area. So we have shows about
JavaScript, to react, angular view and

546
00:50:01.840 --> 00:50:05.599
so on. We're going to have
meetups for all of those things. I'm

547
00:50:05.639 --> 00:50:07.960
going to revive the freelancer show.
We'll have one about that, right so

548
00:50:08.000 --> 00:50:12.760
you can get started freelancing or continue
freelancing if that's where you're at. And

549
00:50:13.199 --> 00:50:19.360
I'm working on finding authors who can
actually do weekly video tutorials on some thing

550
00:50:19.480 --> 00:50:22.760
for ten minutes this related again to
those technology areas so that you can stay

551
00:50:22.760 --> 00:50:27.199
current, keep growing. So if
you're interested, go to toppendevs dot com

552
00:50:27.239 --> 00:50:31.599
slash sign up and you can get
in right now for thirty nine dollars.

553
00:50:31.840 --> 00:50:36.559
When we're done, that price is
going to go up to seventy five dollars,

554
00:50:37.000 --> 00:50:40.920
and the thirty nine dollars price gets
you access to two calls per week.

555
00:50:42.760 --> 00:50:45.519
The full price at one hundred and
fifty dollars, which is going to

556
00:50:45.559 --> 00:50:50.559
be seventy five dollars over the next
few weeks. That price is going to

557
00:50:50.599 --> 00:50:53.079
get you access to all of the
calls and all of the tutorials and everything

558
00:50:53.119 --> 00:50:58.480
else that we put out from top
endevs, along with member pricing for our

559
00:50:58.519 --> 00:51:01.920
remote conferences that are coming up next
year. So go check it out topendevs

560
00:51:01.960 --> 00:51:07.599
dot com slash sign up. Okay, all right, so let's do some

561
00:51:07.679 --> 00:51:14.239
promos just before we wrap things up. So, Chris, what would you

562
00:51:14.320 --> 00:51:19.760
like to promote? Sure, yell, I'll share again what I'm currently working

563
00:51:19.840 --> 00:51:28.199
on. That's code video you can
convert basically with a declarative syntax of actions

564
00:51:28.239 --> 00:51:35.840
and kind of like speech annotations,
you can automate basically educational software videos.

565
00:51:35.880 --> 00:51:39.320
Maybe later it will grow, but
for now I'm focusing on how developers like

566
00:51:39.440 --> 00:51:46.440
us can create quite easily educational software
videos. And ironically enough, it's unfortunately

567
00:51:46.480 --> 00:51:50.920
I haven't built it with BIT,
but I've gone in the direction where I've

568
00:51:51.000 --> 00:51:55.199
learned slowly. Like when you do
an open source thing or project, it

569
00:51:55.280 --> 00:52:00.519
makes sense a lot of times to
break everything into reusable their functions or components

570
00:52:00.599 --> 00:52:05.199
or things like that. I haven't
gotten as low as component level, but

571
00:52:05.639 --> 00:52:08.280
a lot of new packages. Yeah, I might. I might look into

572
00:52:08.280 --> 00:52:12.679
this, uh, into using it, because it makes so much sense when

573
00:52:12.719 --> 00:52:17.119
you break everything into some sort of
reusable function or utail function. It has

574
00:52:17.119 --> 00:52:21.119
its own version, and it has
its own tests. It's way easier from

575
00:52:21.119 --> 00:52:24.400
an open source standpoint. So I
will definitely look into bit maybe to organize

576
00:52:24.440 --> 00:52:30.519
all that nice nice okay, uh, well, in my case not,

577
00:52:30.079 --> 00:52:36.639
I don't have any specific picks this
week, any specific promose, so I'm

578
00:52:36.679 --> 00:52:42.840
just gonna pass the ball onto Gillad. So I imagine that you're kind of

579
00:52:42.920 --> 00:52:52.480
pick a BIT, but maybe there's
some I would want anyone to to take

580
00:52:52.480 --> 00:52:55.800
a look at bit dev and deep
Triple, which is open source most of

581
00:52:55.840 --> 00:53:00.920
what I discovered is open source,
so you can try and it look if

582
00:53:00.920 --> 00:53:04.840
you want. I do want to
promote something something different, just to not

583
00:53:05.000 --> 00:53:09.039
be like, of course I'm promoting
B but something which is not about the

584
00:53:09.079 --> 00:53:15.320
directly to me, which is Home
Assistant. Home as systant is a very

585
00:53:15.320 --> 00:53:19.599
big platform for home automation. It's
also an open source, one of the

586
00:53:19.639 --> 00:53:23.360
biggest open sources in the world,
and I'm using it every day to build

587
00:53:23.360 --> 00:53:30.280
my own home doing some crazy stuff. So anyone who is looking into home

588
00:53:30.280 --> 00:53:37.599
automation and smartoms, you should really
check it out from Assistant. We'll find

589
00:53:37.599 --> 00:53:46.360
it in Gooded in one second and
that's it. Okay, okay, nice

590
00:53:47.280 --> 00:53:52.400
Gilad, Thank you so much.
We definitely have more things to talk about,

591
00:53:52.440 --> 00:53:58.639
so if you ever want to get
into the show again, you will

592
00:53:58.679 --> 00:54:05.079
be very welcomed and I'm sure that
we can talk for ten more episodes probably,

593
00:54:05.519 --> 00:54:08.119
So yeah, very very nice having
you. Thank you for your time,

594
00:54:09.559 --> 00:54:13.880
thank you, thank you for thank
you for inviting me. It was

595
00:54:14.239 --> 00:54:21.280
really great fun and yeah we didn't
cover many many topics, but I would

596
00:54:21.320 --> 00:54:27.480
like to come again whenever it works
for you. So so many to speak

597
00:54:27.599 --> 00:54:34.000
and eventually I really hope that people
will write and use more code and spend

598
00:54:34.039 --> 00:54:38.559
the time building usings and not reinventing
the wheel every day, every day again,

599
00:54:40.400 --> 00:54:50.840
so everyone will enjoy and benefit from
better code bases and speaking development.

600
00:54:52.639 --> 00:54:59.599
Definitely, definitely you're welcome. Thank
you. Oh thanks everyone for speaking until

601
00:54:59.599 --> 00:55:04.320
the end the show. Have a
great week and I will see you in

602
00:55:04.400 --> 00:55:09.400
the next one mm hm