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