 Before we proceed, I would like to start with questions for you, the audience. So, how many of you like listening to music? Alright, how many of you know how to play any instrument? It could be a guitar, a piano, drums. Great, thanks. For those people who raised their hands, how many of you like playing your favorite music? Like chilling out on the couch, taking your instrument and playing while your favorite music is in the background? Awesome, so now we can continue. Hi, my name is Boaz. This is me when I was four years old, three years old, trying to figure out my parents' network. I failed, but it didn't stop me from being an engineer, a threat. I'm playing the guitar in a band called Front Band. We have many cool songs, like I want a pair code with somebody and my favorite one, render me one more time. I also would like to share with you that I'm volunteering in AVU, which stands for anonymous BS code users. So, if you or any of your friends are using it, feel free to reach out for help. So, as I mentioned before, I love playing music. One of the greatest things about it is that I can compose or create my own music. But that's not it. I also love building my own musical style. Sometimes it happens after playing different chords, but most of the time I'm inspired by other music or artists. How many of you know what this is? Correct. That's a picture of music notes. By reading these notes, you can play the music. In other words, this is how I document my music or musical style. And the awesome thing about it is that I can share it with my friends and inspire them too. But why do I talk about this? Defqons is about technology. Well, music is similar to coding. We like using other people's code from, let's say, Stack Overflow. And sometimes we are inspired by them. And of course, we like writing our own ideas in different programming languages like JavaScript, Python, and Go. So obviously our music notes are pseudo-code or any programming language syntax. That's in a way that anyone can read it and implement it in their applications. But there is a problem. How can we explain this to people who don't read code or cannot read music notes? How can we explain to them how things work? And now I would like to focus on what we are doing in the software engineering world. Okay, so let's buckle up because my friend Doc gave me permission to use his time machine. Let me set it up to 1920 and here we go. Who knows what this is? Correct. This is a flow chart and it was invented in this year. And its purpose is to describe an algorithm in a visual way. This algorithm is from the series The Big Bang Theory. In a particular, in that was an episode where Sheldon was trying to figure out how to build relationships. So he made up this flow chart to help him. And the reason I show it is because apparently 65% of the general population are visual learners. Which means that probably 65% of your friends or your family understand and remember things better by sight. We can picture what we are learning in our heads. But let's go back. Are flow charts better to describe code or applications? Well, not always. It really depends on the size or complexity of the application. But definitely it's one of the most popular ways to describe code and algorithms visually. Okay, moving forward. A year 1936, a British scientist named Alan Turing, who you all know, published a paper where he described the idea of a universal machine that could decode and perform any set of instructions. And 20 years later, a publication of Automata Studies was published too. It mentioned ideas like state machines and more interestingly, finite state machines. Now I want to concentrate on finite state machines. A finite state machine is a mathematical model of computation. It represents a machine that has the following rules. First rule, it can be in exactly one of the finite numbers of states at any given time. Two, it can change from one state to another in response to an event or action. But what it really means is finite state machines are a direct graph. Each state is a node and every event is an edge. But isn't it similar to a flow chart? Yes and no. On one hand, they both are directed graphs. However, on the other hand, the flow chart doesn't have the concept of state. It doesn't keep track of what is your state. And that idea is not explicitly driving the process. And yet, the problem here is, can we describe complex or big logic using finite state machines? Unfortunately, not. And probably the flow charts will remain more intuitive than finite state machines. But that's my personal opinion. Nonetheless, finite state machines bring an interesting concept to the table. And that is mapping the software into different states and using events to trigger a transition from one state to another. Okay, let's move forward again to the 80s. Nope, not here. I mean here. This is David R.L. He invented a graphical language for specifying and programming reactive systems. He called it state charts. And the funny part is it is based on a finite state machine graph. However, it has intriguing features that were not introduced in finite state machines. I will talk about them more. The beautiful thing about state charts is that it gives us a better way to represent code or algorithms in a visual way. But is it really the best tool of all? In my opinion, yeah. Because the moment I heard of it, I couldn't stop using it to design things related to work. And later, to my side projects. It gave me the opportunity to work on interesting problems on my way home or in my free time. The more I saw problems, the more I wanted to share or use them later in case I forget. This led me to sketch those designs in my notebook. I'm going with this book everywhere. And if I'm stuck or have time to kill, I always open it and think about problems I want to solve. Now, let's go back to the future. Well, kind of. This is David Korshed. He's talking about a library we developed called Ecstake, which allows anyone to pass a state chart, chase some data, and run their machine on the browser. And the cool part is that he also made a visualizer so you can interact with it, which was a game changer. I could now pass my design to the browser and let my family and my non-technical friends review and play with my work. It helped them a lot in understanding what I'm currently working on and also giving me good ideas or new problems to solve. Okay, so welcome to the demo part. I'm going to solve the stack example where I'm actually building a stack. First of all, I will try to do it with finite state machines, and then I will show you how you can make it better using state charts. And by doing so, we also see the features that finite state machines don't have but state charts have and how it makes it more simple to work with. So let me start with defining all the different states that our stack has. So first of all, we have the empty state and we have the full state. So I render this working because I need to specify the initial state, and that is empty. So let's start with the empty state. Okay. So now I need to define events. So we, on the empty state, we have one event which is push. And this will get us to the full state. And when I'm the stack is full, I can only pop items and remove them. So I have the pop ex sorry, I have the pop event, and it will go back to the empty state. So if I update, you'll see that it's working really nice. And I have here some kind of editor where I can like put the type of event, for example, pop, and I click send, and it will get me to the push. And if I'll try to click on, try to send the event pop, you will see that nothing happens if it stays at empty. But if I'll send the push event, it will go to full. So this is another thing that X state visualizer has. And I like it. Okay, so what we have is a stack with that can have only one item, right, because once I'm pushing an item to it. I need to. I cannot push more on the full state. So one way to like have more than one item is to create another state. This one will call it one. And it has two events. It has the push, which goes to full. And it has the pop, which goes to empty. I need to update those two. That's great. So now I'm pushing at least two items. And I have two items stack. Now, you can see the problem. What if we have a stack with 20 items, then we will have to set state for each one of these items. Another problem is that we have no way to determine what are the items that the stack has. And that's a problem because what's the point of having a stack if we can't see what items we store. One way to solve it is like having here an event for every different items that the stack can have. And obviously what we end up with finance state machines is a huge graph with many different states. While this, it's going to be very hard to maintain or to explain or, you know, to realize what's happening. So let's see how state charts can help us with that. So first thing that it introduces to us is context. And contact is where we put all the things that are not fine at state machine. It could be data structure. It could be a counter, something that has many different states or values. So, because I'm using stack, I will use a memory, which is basically an array. I will have index, which is going to be my counter. And I will have size. The next thing is having a condition or a guard to a transition. I want to do a transition if condition is true. Otherwise, I want to do a different transition on a specific event. So here, let me change the form from a string to an object and specify the target. And I'm going to wrap that thing into an array because I'll have more than one transition. So here I'll put the condition because so called full. Otherwise, it will go to the point because it's really similar to what I have in between. I'm just going to copy paste it over here. Let's look at the full. So very similarly, I have two transitions. The first one will go to empty if the array is empty. The other one will go to in-bit-win otherwise. All right. And again, because it's very similar to the pop in between, I'm going to copy paste it. So now we have the condition that we need to implement it. So condition basically is a function that takes context and return true or false. So it's full if the index is equal to size minus one. And this empty is if the index equals one. Now let's see what's up there. Looks good. But that's not good enough because we need to mutate the context on each one of those events. For that, we need actions. And specifically, we need to use a sign which is a function that returns a function. And it actually allows me to change the context. So to do it, I'm going to specify the attribute. There is the memory. And I'm going to use the function. So we'll get the context and the event. And we'll return a new value for that attribute. So I'm going to push the event value into the right index inside the memory. And in the index, I'm going to implement it by one. The same thing I'm going to do with the pop action. But here, I'm going to set the value in the index to null. Obviously, because the index is bigger than one, I need to use this offset. And I'm going to implement it. So let's put the push in the push actions. And pop. And again, this is really similar to what we have here. So now that we've rendered the data, we can see that push event we're changing the context here. And when we pop, we're also changing the context. Let's see how it looks like. So this is the state cartway. We're in the beginning, index zero. And we don't have anything. So let's go to the event and create a new event. So I'm going to click send. And you can see that my state has the value two. It's index one. And here, if I'm going to click pop, let's go and move it. And go back to the empty state. So if I click pop, you'll see that now it's null. And the index is zero. Let's replay the push. Let's create another one. The value is going to be now 100 and two. I'm going to click send. And I'll click the state. You can see that the data is. If I click pop, the one out of the two, it's going to be null again. That's going to be one. I can always change the size. Let's say I'm going to have three items. I'm going to click update. And let's say this is one. And let's play again. And this time I'll make it four. You can always replay. And here, I've got you to close it. This is going to be a good idea. What good features that X-State has, how it improves finite state machines, but also allows you to play with some of its work. That's pretty much it. But I think we've covered most of the cool things about X-State. And state charts. Thank you for watching.