Hey, welcome to React Round Up, the podcast where we keep you updated
on all things React related. This show is sponsored by ray Gun and produced
by Top and Doves and Onvoid. Top and Doves is very great Top and
Doves, so get top and pay and recognition for working on interesting problems and
make meaningful community contributions. An Onvoid which provides remote design and software development services
on a task basis, so clients only pay when tests are delivered and approved.
In today's episode, we'll talk about bits and composable software. My name
is Lucas Paganini, your host and podcast Joining me in today's episode is also
the host Chris Ruin, Hello everybody, and our special guest Gilad Shoham,
which is the VP of Engineering at bit dot dov. Hi, Nice to
meet you everyone. It's great to have you on the show. It's not
always we get the VP of engineering off the company in the show. Cool.
Thank you. Hey, folks, this is Charles Maxwell. I've been
talking to whole bunch of people that want to update their resume and find a
better job, and I figure, well, why not just share my resume.
So if you go to top endevs dot com slash resume enter your name
and email address. Then you'll get a copy of the resume that I use
that I've used through freelancing through most of my career as I've kind of refined
it and tweaked it to get me the jobs that I want. Like I
said, topendevs dot com slash resume will get you that, and you can
just kind of use the formatting. It comes in word and pages formats and
you can just fill it in from there. So gild could you please give
a pitch to the audience about bit death, what it is, why should
anyone care about it? And then we can get into all the knits and
bits of about it. Sure of course. So bit is basically a tool
chain to build composable software. It helped you to improve reuse and sharing components,
increased composibility and eventually getting more speed of development, more velocity, uh,
and more consistency because your product that's uh, that's like an eye level.
We are working on these problems for the past almost ten years now,
and we'll focused not only on technical and technological issues around this topic, but
also around philosophy and around methodology of how you can improve you have life cycle
workflow h and there are many many sub or blames of issues along the way
in order to make better composibility, sharing and division cool. So the main
premise is about composing software nice. What exactly does Betta offers that I can't
get with other solutions already existing in the markets such as mono repos like Turbo
repos and nx are just yeah, so at least that's where my mind took
me to to mono repos. But I'm not even sure if that's a good
comparison to make. First, it's a great comparison the different comparison or different
category of product that are that are kind of compared against bit. So first,
so fist, let's make some high level presentation of how bit is composed
itself. So bat is composed from two different main parts. One is BATU
the c l I, and the other is bit Cloud, which is a
SASS platform. It's very very similar to to get the guitar. You have
Beats as a CLI. It's an open source project which manage your components and
the cloud which manage which is like kind of a hosting platform for components and
including additional enterprise features like security staff and the hosting and c I and searching.
So when talking about tools like NX and two burripo, first they are
only handling the local development and they are not doing anything related to the sharing
later on. So for example, the entire discovery experience, how we can
find components, how I can experience my components, check what fits me,
analytics about components, usages, and stuff like this, which all these are
stuff that that all the mono reporters are not dealing with. Another very important
distinction is that mono repotools are built around rippers, which basically means they are
the aim to make more centralization of your workflow, while we in bit believe
in kind of the opposite direction of this centralize everything. So in Bit,
many times many users don't use repo at all, not even like a regularly,
but not using Git at all, because we came up with kind of
a concept, which is we call it sometimes like a disposable workspace, which
you just make a new four there, build your feature there, and then
the lead this workspace after it. And this is possible because of one of
the major features on bit, which is the import feature, which means you
can take any component from any from any workspace, any project anywhere in your
organization, and you can develop it in any other workspace or project, So
you can kind of clone the source code of different components into your own temporary
workspace, develop them there, and then deleat the entire the entire workspace.
Another important distinction between the monoreporters and BIT, I think, is that the
mono reports are are are basically doing as a automation for scripts from outside that
run on multiple packages or and linking between the packages, while BIT is managing
your entire life cycle of your component, which means when you do compilation,
for example, on an NX project, the compilation script are basically outside the
outside NX and NX is just calling them to run them on different packages,
while on BIT this is part of the component metadata. And we will discuss
this and in a minute. And the third important distinction is the level of
granularity the tools can handle. So the monoycle tools built to handleckages, when
we build BITS to manage components, which is many times they are very similar
in the technical aspect, but usually it's a different level of granularity. So
for example, if you have let's say something like a design system, you
have one package for design system, but it is fifty components, and we
try to make we build at a tool to make each component like an individual
entity, with its own history, its own package, its own versioning,
it's on everything. So if you try to make like an NX triple with
like fifty components fifty packages, it's fine. But if you take these fifty
packages, which sometimes might be composed from ten thousands from a thousand components,
then these tools are usually starting to to get to a botty lick in many
DEAVE experience aspects. Interesting. Interesting, So it's very well integrated with disposable
cloud machines that you can just use for development and then get rid of it.
That's an interesting feature. And who do you think this feature? Like?
Who do you think is more benefited by such features? Because I'm trying
to think of a scenario where I needed something like this, And maybe it's
just not for me, because I can't think of a scenario where I needed
a solution that didn't require local development. And like I get the concept about
decentralizing that one that one, I can see how that would fit with my
workflow because I could just have parts of my system that I break into other
parts I'm not going to call them other repositories because we're trying to to Also,
as you said, we can also not work with repositories at all and
still have a way to share this code with others. So okay, I
could package it up into a way and then share it with others. Still,
I'm not entirely I'm not entirely seen how this would be more productive to
me, at least than, for example, just publishing a package on NPM
and installing from there. Like, if I really wanted to separate something from
a main repository and share it with others, my approach would probably this,
but yours might be better. I'm just I haven't fully understood how that would
be more interesting than just packaging it up and putting it on NPM, And
also not seeing how in which circumstances the cloud development we're using temporary machines would
be more interesting than just the regular local development. Okay, so great question.
So first, maybe something that was not very clear for my description this
disposable workspace today on your local machine. Okay, so it's just a tempo
for them that you create locally computer instead of cloning the entire report. We
do plan soon to release like a cloud workspace, which will give you the
same experience on the cloudoud and and so so the question so I will split
your question to why should I do it locally on you on my machine versus
why should I do it on cloud? And what and what cloud UH give
me? In this use case, I'll start with cloud because I think it's
like shorter and easier to to explain and and editing on component based on the
cloud is very very good for different types of persons. First, people who
are not developers but working with developers. For example, if you have a
cloud workspace, and cloud workspace BIT is managing the entire life cycle. So
BIT is knowing how to compile your component and also show you a fender version
of your component similar to storybook, and showing you the test results and everything.
So if you are a designer now and you can change the CSS and
see the components lendering and then make a kind of a pull request like we
call it change request right from the cloud without need to set up anything.
This is now a game changer because now as a designer with out most of
the way from designer to production, or if you are a reproduct manager,
and you want to change like a message, an error message or something like
this, you can do it now from the cloud without need to do any
local setup as non developer. This is true also for developers who want to
do small changes in components. So this is about cloud and this is not
available yet. This is in pogress, but on the local machine. What
important is basically you're right. You can take something and package it up and
send it to NPM. And Bit is doing something very similar to this,
but in much better developed developer experience. Because the first let's I will try
to make some kind of farm high level layout of the main problems or the
main stuff that prevent people from sharing and reusing more code, and I would
split it. So the first problem is creation over it. Okay, if
you want more code her, you need to make more code individual consumerble like
NPM packages. But making a new NPM packages from repository with a big project
is a big task. Let's say you want to take your projects and start
splitting it up to many many individual components, and then you take each one
of them and make a new repository, and then you need to set up
all the tool chain you need to set up compiler and CI and tester and
linter and make read me and contribution docs. So in order to do this
in scale, it's just doesn't work. So organizations solve these problems today in
two and two in two ways. One way is that they're doing it only
for the stuff that are commonly shared. For example, design systems, the
design system in the organization or building design system, and this is shared in
NPM and everyone users because they know people will use it. The other kind
of solution people have is to peck many things together. So the design system
they pack together fifty or one other components and then they have like a kind
of a util function library, something like loaded shoranda of the organization, and
this is another one of the components inside of it. Because making one hundred
repositors for the design system and doing everything one other time is just not possible.
And this leads to two kind of conflicts of interest of using this shared
code. For example, if now your design system is composed from one components,
then I'm as a user, lets want to use it because few different
problems. The first problem is that if I only want potion or some components
form your design system and design system is just an example, okay that it
could be like other kind of library packages. And by the way, this
talent true only for frounded. When I see a components in this context or
in the context of FIT, it can be anything. It can be a
ut function, it can be a micro service, it can be even an
application, not only fraunded components. Many of the examples might be one and
related because it's just easier to understand and the audiences are react people usually,
but it's true for also for deeconds and all this world. So back to
the problem of this solution is one that if I only want two components from
your design system, now I'm bringing the entire design system and my bundle side
and my performance are going to be much worse. Yes, we do have
three shaking, but it's not perfect. It's about from perfect. So if
I only need a small part of it, I'm not going to use the
package you published. I'm just going to build my own copy from your design
system. Another problem is the updating problem. Let's say you update the button
components now as a user. If now I need to update the button,
I need to update the entire design system, which will I'm now updating one
our components, and I have no idea what is going to happen to my
product when I update one other components at once. So because I know this
ahead of time that every time I'm using the design system I will need to
update it once, I less likely want to use it and at less likely
to update it when you do changes unless someone forces me. Let's say the
head of design forced me to update the design SISTE version of head of security
forced me because there was like a securge issue that was update. So someone
pushing me from outside to update right now. On the other end, if
these are individual components, then I'm taking only what I need. Then this
problem does not exist from the first place. So the first very big issue
is to make it very easy to make many components individually available and every component,
by the way, every component you expert to be it is available as
regular NPM package and you can install it like any other package using your favorite
package manager PMPM and PM down whatever. So the first thing is like to
automate this entire process. Another big problem on like the creation over it is,
for example, maintaining dependencies and package Jason. Okay, so once you
start splitting all of it, you need to manage one other package Jason and
dependencies. This should be a def dependency here, it's a random dependency here,
and to install it, I need to manage all the versions. While
one of the for example, one of the problems we are dealing with,
is how to make it easy in your own project, even an existing project,
to take small pieces, small components out of it at an NPM package
without need to set anything, and we automate the entire dependency management, so
we know to static cot analysis your source code and add dependencies, automatically,
manage the version, automatically, even manage if it's a deaf dependency or one
time dependency based on if you use it from a spec file or from your
regular file of the component, for example. So this is one thing.
Another big problem is that organizations tend to share the code that they know for
sure that will be used, like design systems. However, because of this
big overread of sharing and creation, they don't try to share other code,
which is in real life, once it's tried, is very very usable as
well. So many product teams can benefit from other product team components. But
these other product teams just don't share this code because they they don't do they
don't want to do this effort of sharing the code of doing all this manual
and tedious process of like started out, makeeeople, make the docs, make
everything set up so you get eventually much let's call chilled in your organization,
then what you can get. Okay, that that does make sense. It's
so much more powerful than I had understood at first. So it's really amazing.
Nice. How long have you been working on this? By the way,
I imagine that you were there from the start, right or probably I'm
not. I wasn't from the from the field day. I kind of joined
once they finished to do like once the founder was finished, to do that
the pivots of any any startup. So it was one of the Fields employees,
and I joined almost seven years ago. Seven years Yeah. Yeah,
this is a very big and complex product. Yeah. By the way,
something that I didn't mention, which is related like to your questions that I
forget to read, is about this disposable workspace. So like I said that
bit, it is not only a technical solution. It's about philosophy and methodology.
Like the philosophy is basically you need to split code and shall more code.
And then in the methodology, one of the one of the stuff is
to help the organization do the mind shift of being more collaborated. So,
for example, when you build a component in the context of a RIPO,
in the context of projects, you tend to make it more bounded to this
context and this project. Okay, because you build it for yourself inside this
context. But if you think about about the component as the let's say the
core entity of you are in the product or an R and D team and
not the project or the application as the cops. So most of the organizations
are building their R and D structure around applications. They build team around application,
they do CICD for application, they do testing in the application level.
And the components. Today everyone builds components, like everyone that uses any framework,
react, you under up whatever, they build components, but they build
components to serve the clunt application. While what we're trying to do in a
BIT is to shifting it so the components are the main thing. Then the
application is just a composition of different components. So when you build the components,
let's say you have a feature, okay, you need to build a
future let's take a real example. You need to make a new header for
your website. Okay, everyone did it in the past, and when you
do, when you do this inside your project, there's more likely that this
header is going to be coupled in different ways to the application. While if
you think about header as a feature, what how it looks like if you
try to think about like the definition of this feature, okay, and the
way we see the definition of a feature is very simple. A feature is
a set of components. A components. Some of them need to be built
from scratch, they don't exist. Some of them need to be used because
we already built them and we need to use it. And some of them
need to be used and modified because we need I don't know new APIs from
there. So if you need now, if now this is the definition of
the header feature, you make a new folder. This folder, it's an
empty folder, okay, And on your local machine you do beat create header
create you and you react components from a template and you start implementing the heather
and then you start to install components like NPM install. You do it with
bit but it's basically behind the scene, just PMPM install mostly then you do
install a logo, and you install a search box, and you install menu
whatever, and then you need to change something because you need to make the
search box, I don't know, collapse whatever. Then you just import the
search box. You add this new feature to the search box, and then
once you finish the head, you build it in isolation. Once you build
an isolation, it's much more likely to be reduced a bit easy. And
then once you finish, you might import the application itself, and you do
for integration purposes, so you bring the application at the end, not at
the beginning. And this only this alone make a lot of changes of the
reusability. And this is like it's like a fake. It's like a fake
change. Okay, I tell a few mentality. You can fake, you
can pose yourself to do it, but once you have the tours and you
can do it for real, it's it just happens much better. Hey,
there, this is Charles Maxwood. I'm excited because I wanted to let you
know about this thing that I pulled together that I had just I've been dying
to have this for years and I never felt like I could. And then
I just realized that there's no reason why I can't. So I'm putting together
a book club and we're going to read development focused books, career books,
you know, technical books, whatever. The first book that we're going to
do is going to be Clean Architecture by Uncle Bob Martin. If you're not
familiar with clean code or some of the other stuff that Bob has done,
check that out. I've also talked to him on the Clean Coders podcast,
which is on Top End Devs. But yeah, we're gonna get on.
He's going to show up to some of our meetings. And what I'm thinking
is we'll probably have like five or six people part of the conversation along with
Bob and I at the same time, and we'll just so somebody can come
on, they can ask their question, and then we'll just rotate people through,
so we'll mute one person, unmute another person when it's their turn to
come on and be part of the discussion. So we'll do that for like
an hour hour and a half. And then the other part of it that
I'm putting together is just kind of a meet and greet gather area on gather
Town, and so after the meetup and the call, we we'll do as
we'll all go over to gather Town and you can just log in, walk
up to a group and have a conversation, and that way we can all
kind of get to know each other and make friends and get to know people
across the world. One thing that I'm finding is that, yeah, the
meetups are starting to come back, but a lot of people don't have the
opportunity to go to a meetup. And I really want to meet you guys
and talk to you. So we're gonna put all that together. We'll all
be part of that book club. You can go to topendevs dot com slash
book Club to be part of it, and I'm looking forward to seeing you
there. The first book club meeting will be in December, the beginning of
December. We're starting the first week of December, and you'll also be part
of the conversation about which book we do next. I have one in mind,
but I want to see where everybody's at, So there you go.
I'm just thinking about how this could have said so much of my time if
I knew about this feature earlier. It's crazy that I'm just hearing about it
now and it exists for well, you've been working on it for seven years,
but for how long has it been like stable and open for public consumption.
So it is available for around let's say three years ago, we did
like a major major version and people will really start using it at scale.
And we did another big changes like about a year ago, which which helps
many organizations start using like sometimes ago. We we we make a lot of
features around the cloud to make it really works good not only for individuals but
also for big organizations. And we can discuss some of I can I can
then take some example of give some example of what it means. So for
example, let's let's take another another big problem in sharing the reusability. You
you start developing, you the feature, and and you use the design system
okay for the menu, and now you need this menu to be uh this
these menu items, like the buttons in the menu, you need them to
be rounded and not square, okay for example, but this feature does not
exist on the on the design system button now in in the real world today,
once you get to something like this, you need to choose your way.
One way is to try to push it upstream, like to the design
system. Okay, so you need now to ford the design system set up
everything, rite, contribution dogs, write, set up dogs, read,
read set up dogs, and set up everything to make this change. And
then you need to do this change and you need to make a pull it.
Weest wait for the review, wait for them to merge it, and
then wait for them to publish it, to publish a new version. And
this is one a very annoying process for you as someone is not part of
the design system team. And secondly, this takes a long time. What
I you're doing in the meantime until it's published with a new version. Right,
you you have a product in pushing you to make something to production and
they don't care that the design system is working slow or the design system have
their own priorities which are different than your priorities. And the other way you
can do is, Okay, I need a change, they don't do it.
I will just copypaste the menu button and I will do any change in
want and I will detach from the design system button. Which this is but
the way what most organizations do in many many cases they detach uh. And
this means once that you have now a problem of consistency, right because they
have the design tomorrow and you don't have this update, and it means that
if they have a bag, they need they fix it, and now you
need to fix it as well, because they don't connect anymore. And the
duplications are going and going all the time. So you're not the only one
that copied is battled. There many other things that copy is batted and and
everyone now needs to fix this bag and to rely the design. If there
is a security hall, then it needs to be fixed ten times. So
it's very costly. On the other end, it gives you kind of the
edge of getting to production faster. What we build in order to kind of
handle this entire let's say cycle. Okay, this this happened every day for
every company, for every developer. Okay, it's not something that people don't
know. But we came up with a different approach to solve this, and
we build a concept. We called it a lane. A lane you can
think about lane as a similar term for git brunch okay, but not but
like a multi report git brench okay, because if you think about it,
each component is kind of like a mini repository. You can it's it has
its own version in and you can import it to any workspace, kind of
clone it to any workspace and change from any workspace. So LANE is when
you aggregate many changes across many components. And these components might be you components
that belong to your team, and there might be someone else components like the
design team component, the security team components, whatever team. So you try,
You start to build a features, and you build new components, and
you change components from other people, and then eventually you make a change request.
A change request is very similar to pull request in guitab, but there
are a few different very important the distinction. The first is that you change
components from different teams. Okay, so now you do a review one review
okay, like an atomic review for you lane, because your lane is like
one entity for many components, and this review should be done by your pills
from your team and by people from other teams that you change the code okay,
you don't have permission to publish or push code to the design system team,
so someone from the design system team need to improve it, and and
so you do like a like realistic review one for many components, second for
different teams. Third is that you do review for different roles in the organization.
Because bit is similar to get in a way because it's it's a version
system. But our entity that we've version is a component and the component is
a much more complicated entity than a file. So we version from each component.
Each version contains not only the source code, it contains only also the
artifacts for example, the bundle of the component, the package, top of
the component, the compiled fives and it contains configuration for this component. And
this is something else that we should talk about, like how you compile,
how to compile this component, how to test this component, how to link
the component, so different configuration of the components. This is part of the
component version. And also it contains like the dependencies. So when you do
review, different types of people from different roles doing review. So you have
review code review from the designer, from the developer, and you can also
see the rendering compared rendering side by side, think about like storybooks by side
that the designer can add comments on the design and then you have like an
architect that comment on changes on dependencies. So and the product that can uh
that can do a review, and technical writers that can review the do commentation
of the component. Because it's also part of these comparison. So we compare
source code, compare rendering, compare dogs, compare test coverage, compare test
results, compare everything. So different people are doing the review, and the
review is also on different types of changes, because when you do change components,
you only you don't only change code. Sometimes you change you change dependency,
sometimes you change the configuration. Now this was used in types four,
now it's uses types to five. Before it was using linting with these rules.
Now it's linding with different rules. So you do many kind of changes,
and then you do a full review on all these aspects. And then
once you merge the lane, then these components are shipped across the entire change
and an entire organization. So you can now have an atomic atomic review and
atomic merge for your entire feature. And then the next step of it is
kind of propagating, propagating the changes. Okay, Let's say you are a
design system team and you make a new version for the button. Okay,
now you now, now what you want is to make this button ship it
in production as soon as possible. But but other teams need to adopt your
button. It takes time. So what we built is is a new type
of CI. Okay, all organism and all cis today are built around applications
and projects, which mean you the CI is first doing a Git clone for
the entire project and then start doing something on the project level. But we
build a component level CI, which means once you change button, we will
test button alone, and then we check the card that users button, and
then we change. We checked the grid which has a lot of cards,
and then we check the page which uses this grid. So we kind of
building a graph because bit is like we said, you know, a build
is a weal for the entire graph of your organization components. So we build
a graph and we start propagating change from the smallest component or the the most
nested component up to the entire organization, and we can now filst We get
a very very fast CI. Why because one because it's parallelized in the component
level, so each component gets its own container. Okay. Secondly, we
only check and we only run what is affected from these changes. Okay,
and and the like the seis of this draft might be a few components.
Okay, let's say your name might you may you might change five components at
once, So we only check what is affected by these seeders, and we
parallelize it to the maximum. And now also for the first time, you
can see visually how your components changes will affect people or components from other teams
that you don't even aware that you're using, that they are using your code
in the visual ways. So you can see that the button that you change
is breaking the about page that maintained of course by like a product team.
And now you can talk about you can see it in one place and talk
about why a pattern change break the depout page. Okay, and you can
communicate about this change. Maybe you did the breaking change in the API.
Maybe they use an internal API from the pattern, but they shouldn't use that's
why they break. But now even before you publish the patent okay, and
then today world, what happens usually is the design system published the paton or
the design system and then two months later some team is updating it and then
this is that it's breaking the other team and they didn't know about it.
You can take some now even before the merge, you know that the paton
change will affect someone else in a bad way or in a good way.
So this is another important process of it all. This new feature like the
CI and the product review and the code review or change request review land review
available around they so this makes a big change in the market of big organizations
that starts adopting it. Understood, understood. So we we spoke a lot.
Unfortunately, there's just so much more than that we could talk about.
Uh. You mentioned before we started to show that you could speak about this
for three hours, and now I can see that this was very serious.
Like I think three hours is is not that long. Actually, I think
we would need a lot more than that. There's a lot of interesting things
to talk about, uh, to talk about bits. So but unfortunately we're
gonna have to start wrapping up this episode just so that it doesn't take super
long. But before we start wrapping up, is there anything that we haven't
talked about yet? And you think that we definitely need to talk about this
before finishing this episode. I think that's maybe kind of one more important feature
or concept that is that is interesting just to give a glimpse, and this
called the component environment. Component environment is basically a component, okay, so
we kind of have a special kind of components basically implement some kind of interface,
which are components that manage other components life cycle Okay, it's a bit
complicated. I would try to simplify it in a second, in two minutes.
So let's think about created act up okay, and let's think if you
could take created act up and then put it into a component that you can
extend or modify in the organization level, in the group level, in the
department level, in the team level, and you're versioning it and you can
customize it. Okay. So basically you can create this kind of component environment
components in your organization for different types of component. Let's say you say this
is my environment for React components. It contains stuff like how to compile React
components, which types of configuration or bublic configuration, how to test React components,
which tool you are used just with something else, linking configuration, retail
configuration, bonding configuration, whatever, and then and it also contained templates,
so the environment is also registering templates. So I have templates for Reactive I
components, a template for React cook a template for the reactiplication for example.
And then you have like a node component, and then you have I don't
know, an MDX component type, different types of components. Then when you
create a new component, you just a touch we just mentioned which type of
component it is, and then all this configuration and everything is like, uh
like hidden from you and the platform of the organization. You manage this environment,
but this gives you like one unified experience. So in one workspace,
you might have React components, Angular components, Note components and the ex component
in the same place and you just take bit bait compile all components. Okay,
and you don't need to know how to compile components. If you input
a component from the cloud, you can just a bit to compile it to
lind it according to the author original standards. And even if you use different
tools. So some components in your works this might use such steps, some
long, some use just some use tests and you get one unified output of
everything that by bit applying each environment on each component and aggregate all the results
together so you don't need to mess with it. You don't need to do
anything. Uh And this increase a lot the way of creating new components that
are easily show a bit and we use a bel because you don't need to
do anything related to configuration. Did that? There's just so much there's just
so much to cover. Yeah, Chris, you good like do you want
to ask anything before you start wrapping up? Yeah? I did just two
quick questions. So the first one I noticed, like I'm on the homepage
here and you can learn the various ways there's there's no and angular and view
and react. Are you guys interested or is it in the pipeline because I
know a lot of people they'll they'll of course do their front end and JavaScript,
but the back end they'll do something like go laying or c sharp or
something like that. Is there any is that in the planning to somehow support
I mean even like some fancy who knows some sort of business logic function in
the back end that's written in some other like a non JavaScript language. Is
there anything like that? So basically, most of it, most of the
technology we built, we build it in a way that is language agnostic.
Most of it, most of the concept are not bounded to the JavaScript or
web world. However, there our SUN features like dependency management and installation and
staticod analysis and passing, which is of course our language specific. We do
plan to support more languages in the future, but we not there yet.
We don't have any even not even a rough time on when we're going to
start working on it. Cool, awesome, and then the other thing.
This goes way back to the beginning of what you mentioned. You get some
I think you mentioned you can get analytics or logging for your components and things
like that. Is that configurable or like, for example, if I have
just like a button, I don't think I need you know, some generic
button, I don't need logs or something like that. But like I don't
know some sort of checkout component there, I want some analytics and logs.
How how does that look? So basically, today the entire analytics feature is
pretty new, and we are building all the time new even just before the
meeting, we build new new analytics around measuring collaboration and use because in today
you don't even know how much to collaborate or share. Basically it's usually kind
of near to zero. But for example we build for we monitor for which
component, how much dependency is, maybe how much impact it is, like
kind of recursive recursive usage of it, and then we aggregate this in the
component level, in the scope level. It's like a group of components in
in the business domain, in the scope level, in the organization level.
So we add all the time different way of measuring the effort you put.
So you make a component, how much value you get from it, how
much? How many people are using it? Are they using an up to
date version? How many people are using an old version of this component?
How many people using two versions of this component in the same three but in
different versions, which means kind of in consistency and balanceize problems. So and
we build different way of analytics all the time. You don't need to do
anything to get this analytics. We we've analyzed the graph, we analyze the
user to analyze the source code all the time, and we just give you
this. It's part of like the cloud of of course, cool, very
very cool, very interesting stuff. Thanks nice. Have you ever wished that
you had a group of people that were just as passionate about writing code as
you are? I know I did. I did that for most of my
career. I'd go to the meetups, I try and create other opportunities,
and it was just really hard, right the meetups. I got some of
that, but they were only like once or twice a month, and it
was just really hard to find that group of people that I connected with and
really wanted to talk about code a lot, Right, I mean, I
love writing code. I think it's the best, and so I've decided to
create this community and create a worldwide community that we can all jump in and
do it. So we're going to have two workshops every week. One of
those or two of those every month are going to be Q and A calls
right where you can get on you can ask me or me and another expert
questions. The rest of them are going to be focused on different aspects of
career or programming or things like that. Right, So it'll go anywhere from
like deployments and containers all the way up to managing your four oh one K
and negotiating your benefits package. Well, we'll cover all of it, okay.
And then we're also going to have meetups every month for your particular technology
area. So we have shows about JavaScript, to react, angular view and
so on. We're going to have meetups for all of those things. I'm
going to revive the freelancer show. We'll have one about that, right so
you can get started freelancing or continue freelancing if that's where you're at. And
I'm working on finding authors who can actually do weekly video tutorials on some thing
for ten minutes this related again to those technology areas so that you can stay
current, keep growing. So if you're interested, go to toppendevs dot com
slash sign up and you can get in right now for thirty nine dollars.
When we're done, that price is going to go up to seventy five dollars,
and the thirty nine dollars price gets you access to two calls per week.
The full price at one hundred and fifty dollars, which is going to
be seventy five dollars over the next few weeks. That price is going to
get you access to all of the calls and all of the tutorials and everything
else that we put out from top endevs, along with member pricing for our
remote conferences that are coming up next year. So go check it out topendevs
dot com slash sign up. Okay, all right, so let's do some
promos just before we wrap things up. So, Chris, what would you
like to promote? Sure, yell, I'll share again what I'm currently working
on. That's code video you can convert basically with a declarative syntax of actions
and kind of like speech annotations, you can automate basically educational software videos.
Maybe later it will grow, but for now I'm focusing on how developers like
us can create quite easily educational software videos. And ironically enough, it's unfortunately
I haven't built it with BIT, but I've gone in the direction where I've
learned slowly. Like when you do an open source thing or project, it
makes sense a lot of times to break everything into reusable their functions or components
or things like that. I haven't gotten as low as component level, but
a lot of new packages. Yeah, I might. I might look into
this, uh, into using it, because it makes so much sense when
you break everything into some sort of reusable function or utail function. It has
its own version, and it has its own tests. It's way easier from
an open source standpoint. So I will definitely look into bit maybe to organize
all that nice nice okay, uh, well, in my case not,
I don't have any specific picks this week, any specific promose, so I'm
just gonna pass the ball onto Gillad. So I imagine that you're kind of
pick a BIT, but maybe there's some I would want anyone to to take
a look at bit dev and deep Triple, which is open source most of
what I discovered is open source, so you can try and it look if
you want. I do want to promote something something different, just to not
be like, of course I'm promoting B but something which is not about the
directly to me, which is Home Assistant. Home as systant is a very
big platform for home automation. It's also an open source, one of the
biggest open sources in the world, and I'm using it every day to build
my own home doing some crazy stuff. So anyone who is looking into home
automation and smartoms, you should really check it out from Assistant. We'll find
it in Gooded in one second and that's it. Okay, okay, nice
Gilad, Thank you so much. We definitely have more things to talk about,
so if you ever want to get into the show again, you will
be very welcomed and I'm sure that we can talk for ten more episodes probably,
So yeah, very very nice having you. Thank you for your time,
thank you, thank you for thank you for inviting me. It was
really great fun and yeah we didn't cover many many topics, but I would
like to come again whenever it works for you. So so many to speak
and eventually I really hope that people will write and use more code and spend
the time building usings and not reinventing the wheel every day, every day again,
so everyone will enjoy and benefit from better code bases and speaking development.
Definitely, definitely you're welcome. Thank you. Oh thanks everyone for speaking until
the end the show. Have a great week and I will see you in
the next one mm hm