 Hello everyone. Welcome to the Fast Track to Becoming a Hyperledger Cactus Contributor breakout session. I'm not sure if you can see my camera or not because Hoppin just showed some warning that says that you may not, but that's fine. As long as you can see my screen trailer, we should be good. So what we will do today, I will demonstrate how to set up a development environment and will sort of time travel through that process because certain commands you actually can take up to half an hour if you're on a very, very slow computer, but you'll see how to do it from the beginning, from get cloned all the way up to you being able to debug test cases that you wrote to verify that the cactus component or the change, the bug fix, the feature that you made actually works. And with that said, there's a list of prayer requisites that I carry. So the prerequisites is to have Docker installed on your machine and Visual Studio Code and a specific extension pack for Visual Studio Code, which is called the remote development extension pack. And I've included links to all of these here so that if you're following along, then you can just go through these links, download and install everything. And then you should be ready to carry on with the rest of it, as I will show it. And there's a recommended read, which is optional. That's the bottom link that says Dev Containers. That just gives you a little background info on how development works. The two sentence summary of it is that VS Code can launch a container for you. A script will set the dependencies of the project where the project here is Hyperledged Cactus. And then in that container, you have a stable and reproducible build development environment, which is guaranteed to work. Of course, nothing's ever guaranteed as just the recent events demonstrated, but it has a much, much higher probability of actually working versus you trying to install the build dependencies of the project straight up onto your host operating system, whichever that may be. And then the other thing that I wanted to highlight, and I will continue highlighting this because it is very important for me to, for everyone to notice, is that we run daily pair programming sessions every weekday in the morning hours of Pacific time, VS Code. And you can get the details of that through our wiki page, which is linked there. The fine print sort of there is that these sessions will be canceled for today, tomorrow, and first day because of the Hyperledged Global Forum, because it's difficult to attend both at the same time. We're very, very busy with the conference itself. But other than that, come Friday, for example, or any other day after that, you're most welcome to just drop into one of those calls, share your screen and say, hey, I have a problem. I either cannot get the build running or the compiler is telling me some error messages that are not making any sense whatsoever. And we'll be happy to take a look at it and just try and figure it out together. So the actual setup, you would start where they get cloned. And there's the project link for that. If you struggle with this part, then I also recommend our pair programming sessions, but I did not have enough time in the scope of this session to explain also the basics about how Git works. So that part is implied that you need to have Git installed here and you need to be able to have access to some sort where you can actually clone. And then regarding our repository structure, just a really quick note, we have a mono repo, which means that instead of having a bunch of different Git repositories for every package that Cactus ships with, we have packages all embedded within the same Git repository, which sometimes makes it a little more confusing. But once you get to know it, it actually makes it much simpler to manage and navigate. And with that said, I wanted to show you the dev containers in action. Basically, if you start up Visual Studio Code after having installed it, and then you clone the Cactus repository, and you open that folder with VS Code, then it will show you a popup that says, do you want to open this in a container to which you should say yes. But sometimes people miss that little dialogue. So I specifically wanted to start here from a state where it's already in progress and the dialogue is not there. And I wanted to show that you can always hit F1, get to this menu, and then type container, I believe, that's just a little laggy, or maybe dev container. Yes, so you can either hit this one, remove containers, explore volume in a development container. But there's a category that says open, which I'm going to hit now because I only did before the session. Then you can basically just kick back and relax for a long time because it will pull up an entire fully functional development environment for you from scratch without you having to interact with it whatsoever. So that's added value that comes from this, which at first seemingly probably looks like a little bit of an overhead. And so it is actually in progress on my machine right now, this is a live demo. But since it takes up to half an hour to complete, I'm not going to wait for that right now. Obviously, I'll just skip ahead the part where it's already in a state of being. So this is a different window, but it's the same thing. It's the same repository. It's just that in this window, we are seeing the project in a state where it has already been finished. So this is where you'll get after it's completed. And then once you're here, what you can do is actually start making a change to the caxi source code, becoming a contributor. And what I want to highlight there is this is about becoming a contributor, meaning changing the framework itself. This is not a tutorial on how to be an application developer using cactus. And it's important to emphasize this difference because it is orders of magnitude easier if you're just looking at it from the application development perspective, because then all you need to do is just install the right packages via NPM into your project and just use them as dependencies. And there's nothing else really for you to set up apart from that. So with that clarified, I wanted to really quickly demonstrate the botched script that we have, which means that if you are standing in a terminal, you can run the NPM script called watch, which will take a minute to run, but then it's actually watching all the projects in the project to see if they get any changes to them. And if you make a change to the source code, you can pile it, and then the changes will get applied. And this is a great way to enhance your development. If you are working not exactly sure how to actually implement, then it is great to have this fast iteration cycle. I can just blur out some code that does something that you're not even sure maybe what it does. At least that's how I am most of the time. And then just see if it passes a test. It's very convenient. And I think it just disconnected from the server, which is a bit annoying because in my demo, but this is what you get if you're trying to describe the recipe. I was going to start the watch script and then stop the code and demonstrate how a test is breaking because of that change. And then I would fix it. A few seconds later, I would re-execute the test and you would see the test passing. And know that to say that if you have the right setup, which I'm trying to show right now, I think the video call and it's just too much for us guys. But in the meantime, does anyone have any questions? I'm not giving up on this. I still want to show that it actually works the way I claim it does because it does. I do this every day. This is my act. I hope it's a cactus. Let's just double check this. Oh, this doesn't work. I think I should need to take it. So it's probably best if we just get a little bit of Q&A and there's no question about that extra five. Let me have the data pack program. So, feel free to enjoy. That's it for me. Thank you.