Thank you everyone for being here. I know last couple of days were scary with the weather and the changes. So a round of applause for the organizers. They did a really good job of keeping us updated and organizing the whole event. So today, we are going to talk about integrating infrastructure as code into a continuous delivery pipeline. What are the various considerations, any best practices that are there, and the patterns that we have used in the past? But before we get started, we'll introduce ourselves. My name is Adarsh Shah. And I've been in the industry for a long time, doing a lot of various things, but focused on DevOps and cloud computing lately. And I'm Matt. As we said, working in DevOps, doing the DevOps. Love DevOps days, first time doing it in Baltimore. So glad you all could have me here. And we both work for Contino. Contino enables enterprises to accelerate innovation through adoption of DevOps and cloud computing. If you have any questions about the presentation or Contino, Matt and I will be around after the talk today, tomorrow. So feel free to talk to us. So the first thing we're talking about is infrastructure as code. And it pretty much describes itself in the name. There isn't much more to it there. But it begs the question, why do we want to do infrastructure as code? And the general idea here is that we want to apply the same practices we apply to deliver our software, not the changes we make to our infrastructure. And if you're not using infrastructure as code, there are certain challenges. First one being configuration issue. You might have a configuration drift. Because if you're managing your infrastructure manually, you don't have automation. It becomes very difficult to keep your configuration in sync. Repeatability, human error, all of those issues. Time to complete, because if you're doing things manually, it takes longer to complete. So all of those issues come in when those are the challenges when you're not using infrastructure as code. The other thing is we mentioned was continuous delivery. And we could think of that almost as the umbrella term for all of the practices that we've developed to test our software and get it to our users. The book was written by Jezz Hubbell and Dave Farley a number of years ago. This was the first mass introduction outside of people already doing it. And the general idea here is that we want to get those changes to our users quickly, safely, and especially at a steady pace. But that's really high level to impact this a little bit. I think this is really the main underlying principle here is that we want to work in single pieces, not batches. All the reasons up there are pretty self-explanatory. But you might see this and think it's funny. Like, this is a manufacturing example. They're building widgets or something. But we can think of our code and our commits in the same way. Each commit is a piece of product that is going out to our users. And we want to make sure that that piece of product is ready to go and there's no defects in it as quickly as possible. We do that by getting it out to our users as quickly as possible, not letting them pile up in the middle of our system, as you see in those boxes there on the slide on the left. So now that we talked about infrastructure as code, talked about continuous delivery, we want to look at various considerations and best practices when you want to integrate infrastructure as code into a continuous delivery pipeline. And we'll also be talking about some of the best practices with infrastructure as code and continuous delivery on its own as well. So let's get started. OK. So the first thing to mention is source control. This slide might look familiar. We basically pretty much clipped it from 10 deploys per day. If you're not familiar with that presentation, definitely would recommend to go watch it. But all squad haven't talked about basically everyone knows where to look. If we put all of these things in code and it's shared and it's available to everybody, it's no longer a secret what's running or what somebody's thinking because that code is available. Anybody can check it out. They can run it and make sure it works. And so as I just mentioned, we want all of these things in source control, the things we're talking about today infrastructure as code. So there is those actual infrastructure definitions themselves, but any configuration management, any test code, CI, CD, job definitions, we really want all of these things in code so they can be source controlled and that they're accessible to everybody so they can check them out, submit issues, make suggest changes if they need to. We'd also say that we want to modularize our code. This will create a well-defined interface in the sense that if I'm an infrastructure person and I'm now creating an infrastructure module, somebody can go and consume that. They don't need to ask me to go ahead and do it. I understand what this infrastructure should be because somebody's defined like reasonable defaults, maybe some non-negotiable things in it. And all of these things combined, we just want to make sure that we point out like that enables collaboration. There's this thing now that both sides, the person consuming it and the person publishing can work around and collaborate on. So the last thing to mention is that your infrastructure process right now, there may be somebody doing it manually. You might have a document there. The chances at any given time that document's 100% up to date, it's usually low. When you're writing things as code and it has to be executed, especially a lot of these tools that are in declarative format, that code serves very specifically as documentation. You know exactly what the infrastructure is because it's declared in this code. One final thing, so we're also talking about the continuous delivery part. If you're putting your IC code into source control now it's triggering off some type of automated CD job. You don't want to break the workflow, the tool you're using. So this is an example of like a TF plan. So Terraform has this workflow where you do a plan and then apply and it tells you what it's going to do ahead of time. So you still want to make sure you're using that workflow. So at some point during your process, still do the TF plan. You should still have somebody check the plan and make sure it's good to go before you apply. So like for your software, you should be thinking about automated tests for your infrastructure as code as well. So here's a test pyramid that shows if you go from bottom to up, the costs, the maintenance, the brittleness and duration of the test go higher. So it's a typical test pyramid that you see with how explaining it for your software testing. But at the bottom, you'll see it starts with static analysis. If you're using Terraform, you can use something like Terraform validate or TF lint. And there are other static analysis tools with all of these other systems. So you should be doing that and you should be running that as often as possible, even integrating with your IDE. So you know if there are any syntax errors, any linting errors as soon as possible. The key thing is getting fast feedback. And as you run this, because these tests are fast, you can run it as often as you want. So after static analysis, as you go up, there's unit testing, like for your application, there are cases where it makes sense to run unit tests for your infrastructure as code. One example I would give is, let's say you have bash scripts and you have some logic in your bash scripts, you can use BACS as one of the frameworks to test out your logic in bash script. You can even stub and mark your dependencies. So it is a truly unit test. You're not calling your dependencies. So that's unit test for you. If you go up, it's integration tests.  This is valuable because, let's say you're spinning up instances on AWS and you can spin up an fMRAIL environment and runs your tests using InSpec or GAUS that validates that whatever you're expecting your code to do, it does that. But you have less of those integration tests because you should be covering most of them as part of either unit testing. After that, if you go up top, is running a smoke test. The best way to test if your infrastructure works and it's configured correctly is to run a dummy app. So let's take an example of setting up a Kubernetes cluster. So if you're setting up Kubernetes cluster, the best way to test if that works or not is run a dummy app on it in a container and then run some smoke tests. Use something like Selenium or one of the other frameworks to just do a smoke test to verify that you can actually run an app in that cluster. Yeah, so there's a number of, security is a huge thing for all of us, right? Especially with infrastructure. We need to make sure all the ports aren't open or et cetera. Right now, a lot of the time, the way we do this is through handoffs. Like somebody will set up an infrastructure, security team checks it. And we want to break out of this pattern. We want to be able to do these checks again to take this piece of product or commit or code change and know that it's free of defects as soon as possible. So we want to take these same things that are being done maybe by a person right now and build them into our system so that they can happen automatically on every single commit. And these are some of the examples up there. And outside of the checks, we actually want to do as part of our continuous delivery process. There's also security considerations you need for the CDE process itself. So we would definitely say make sure that you have some type of consideration for your secrets management. If you just have like a single Jenkins master instance with all the credentials in the world in it, that's probably not the best way to go. So you want some type of solution there to make sure that you're doing this in a secure way. And if you're building some type of artifact, it's always good if you can sign and verify it so that when you do pull that artifact into your production system, however you're gonna run it, you know for sure that this is the thing that you checked and that it's free of any defects. So like for your security, you should be also thinking about compliance. I'm sure a lot of you work in an industry that is heavy compliance like finance, healthcare and all of the other industries that have compliance like SOCs, PII, HIPAA, PCI, all of these compliance requirements are there and traditionally compliance teams kind of have paperwork. They do these checks manually and they check those boxes with compliance is code. You can actually automate all of that. And by doing that, you can run those tests or your compliance checks early on in your process so that you can verify if you're compliant or not with your infrastructure, even with your apps. And when you do that, you find those issue early on and fix it so that you're not waiting till the end to find out whether you're compliant or not. So it gives you faster feedback. There are certain frameworks available like you can use inspect for that and also HashiCop Sentinel that came out last year that allows policy as code. And I'm gonna give an example here. So if you can see the code there, it's self-explanatory but if you see what this is showing is if you are updating some critical data, it's only allowed if you are part of a certain team and if you have multi-factor authentication enabled. So at the bottom, if you see the last three lines that says that is multi-factor authentication enabled and are you part of the SysOps group and if you are then only you're allowed to change that critical part of data. So there are compliance requirements. I think PCI has where in certain scenarios you need multi-factor authentication to do an action and something like this helps you to automate it and if you integrate it as part of your continuous delivery pipeline, you can run it sooner in your pipeline and get feedback. So we talked about various considerations. We talked about security, compliance, we talked about testing, we talked about source control but now let's look at some of the patterns for provisioning your infrastructure. The ones that we'll be talking about today are up there immutable VMs where you have immutable images. If you don't know what immutable is it's basically you can get rid of it. It's immutable as the word says it's against running long-lived VMs. So we'll be talking about that. We'll be talking about containerized services. So if you are using containers and using container management platform, how do you actually provision and some of the patterns that you can use? And the last is base image and app pool. We'll get into that when we discuss it. So yeah, the first example is using immutable virtual machines and this will be the most in-depth example. So there's a lot of repetition between the three and it's just to show in some different contexts how these things all work together kind of in the same way. As Adarsh mentioned, if you're not as familiar with concept of immutability pretty much it means that we're not gonna change config on running servers. If we wanna update a server, we're gonna bake a new image and then we're gonna replace the old image with a new one. And one of the patterns like he mentioned this is a good practice for is that it doesn't keep long-lived servers, it helps prevent configuration drift. A lot of the things that he mentioned and one of the first consideration slides. But yeah, let's jump right into it. So we don't wanna get too in-depth here but there's some general CI process that you don't wanna prescribe exactly how to do this. But to the extent, if you have any code that can be unit tested, you would unit test it here. But if you're using declarative format type infrastructure as code like Terraform or CloudFormation or whatever it is, more likely there's really gonna be some type of static analysis. If it being declarative, there's not much unit testing going on with those things. But at that point, once we then have a commit that's being merged into master and we have a potential release, we want to pack it into an image and you could use a tool like Packard to do that. Also, I might as well throw out right now. We're using some very specific tools up here to help demonstrate this. We're not necessarily saying you have to use these tools but it helps with the explanation. But at whatever point we do pack an image, it's in some type of staging, a WS account or something. We wanna test it so we're gonna deploy it to an environment. So then we can do some of those slower tests that you saw in a Darsh's pyramid, integration test, security checks. But to be specific, this is at the VM level. We're checking this VM, so you wanna keep it obviously limited to those things.  But whenever you have those checks that are part of your system pass and to your extent that you wanna do, make sure that it's free of defects, we now have something that we think is releaseable that we can deliver to our users and we will publish it to that artifact repo if we're using AWS as an example and this is an AMI, you have your AMI repository and AWS account and now it's available to be consumed by your infrastructure as code. So the same pipeline would go through a similar process in running your Terraform code that I had previously checked through your CI process. So again, we wanna deploy this to an environment so we can run some checks on it. In this case, it's the opposite of the one I mentioned before. The Packer example was related to the VM. In this case, it is related to whatever this module is and I totally forgot to explain what the module is. So it's set on the prior slide, maybe you read it, if not, I'll catch you up on that right now. So we're talking about like a complex app here, like something that's multi-tier, it maybe has something to catch cluster like Reddit. So you need to build images as part of this infrastructure module to deploy that cluster to your AWS account in this example. But we also need to deploy our application VMs too. So there's two packing of images here. The first one in the infrastructure module is about building that cache cluster. Maybe you have a specific requirement for how you build your Redis cluster and that's what it's doing in the bottom there. But same idea, now once that's done, we can say that this commit is published, we're ready to deploy it, deliver it to our users. There is no artifact in Terraform so you're probably pushing a tag here or some other way of tracking this change and saying that it's a release. And then at that point, I could consume that image that was built in the prior process. So then there you go, you have your Redis cluster. And then yeah, it deploys AWS. So top part, we're gonna talk about the application a little bit. And we have this one shaded out purple because this talk isn't really about your application CI process, it's not really about your application testing at all. It's about how do these two things interface. So whatever process there is for building your application and checking that it's ready, you're gonna do that. But at this point now, we are talking about immutable VMs. So this change now has to be baked into a new VM image. We could use Packer again to do this and we wanna follow a similar pattern to check to make sure it's defect-free that we did for the Redis cluster. So same thing here now. We have that box that just says app test that's extremely broad, but basically what we're saying is if you have any higher order tests that are end-to-end smoke tests, it would probably happen the same time you're doing these new infrastructure type checks that we're describing now. Same as before, once that image is done, we're gonna publish it and then we need to be able to trigger off our Terraform steps again so it can go through that same process, pull that new image and deploy it to AWS. Cool, so now let's talk about containerized services. I'm sure a lot of you use containers and if not looking to move to using containers. So what we'll be talking about here is the infrastructure module to actually set up a container management system. And then it's also fully decoupled, like for the VM, immutable VM option. You had a decoupled pipeline for your apps and for your infrastructure. Similarly for containerized services, we'll show the same. And last here, its apps are deployed using the container management system tool set. So whatever tool set is available with your container management system, you'll be using that.  After that comes the testing and validation phase. And you see here, it's a little different diagram here. We're not using Packer here because I'm assuming that you're using one of the pre-baked images that are already available. But you use that and then you bring up an ephemeral environment.  This part is really critical from what we see. Traditionally organizations have separate compliance and security teams that get involved later on in the cycle and then they find out issues right before going to production. But by doing this early on, you actually find those issues sooner rather than later. After that, you set a form and you can spin up your resources on AWS and set up your Kubernetes cluster. Once that's done, your infrastructure is ready. Your container management system is set up. And then looking at the app side at the top, again, it's grayed out because our focus is not the app testing and app CI process, but you have some kind of CI process there. After that, you build up your Docker image, run some tests around that, and then think about security here as well. So you might wanna scan your images using Clare or there are other scanning tools available. They check for any vulnerabilities that are there in your images and a lot of other checks to validate that you don't have a security issue with your image. After that, you might wanna use something like Notary, which actually certifies your image and validates it when you are actually using it to make sure that it is the image that you published. And then after that, you can push that image and then that image will be consumed and deployed to your container management system. So as you can see, in your continuous delivery pipeline, you're thinking about all the various aspects that we talked about earlier and at various stages and trying to move those practices to the left as much as possible so you get early feedback. So the last example is not immutable, we're the first two are. Docker containers force you to work in an immutable fashion. This one we may not recommend, but this is a perfectly legitimate way to do it.  So you need some type of process to make sure you're killing those things off to make sure that your configuration is in sync with what it actually should be. But another thing to point out here too is our infrastructure module. We're packing an image like in the first example, but this is the base image for application where in the first example, we were packing some supporting infrastructure and then we built our app image as part of our application process. So that's a big difference here and we'll just go through this really quickly and point out the differences. So again, as I mentioned, we're still packing that image in the bottom part, but now this is our application base image and another one of the consequences of this, we're deploying this environment to test. We have to use Adarsh's dummy app example here now too, but this is literally just to test this server pretty much because it's not tightly coupled to our application, which may or may not be ideal. But the benefit of this is that you can update your apps really, really fast. And if we jump up to the top part, you see we have a little Gradle logo there. I wasn't sure what would be a better example, but for years, and I think they still do Netflix packages like all their stuff into Debian packages, they used to use Gradle, they built their own tool eventually. They do work in an immutable fashion. They have a tool called Spinnaker, which is an alternative way to do immutable infrastructure. But in this case, since we're not doing that, we just pack that Debian image or RPM or whatever it ends up being, doing the same checks that again, we can't necessarily do directly with the image that we built before. We lose a little bit of the certainty there. But once we've done that check to our level of success, whatever we say is our definition of done, it can get pushed off to some type of repository. It can be something as lightweight as S3. It could be a full blown Debian repository type thing. And once that's actually done, we need some way to tell our servers that there's a new app available.  So I've seen console used to do this in a really nice way. If you're already running console, you can have like a KV there that keeps track of the latest version of the application. The application servers monitor that and then they update themselves based on that change. So we talked about the various patterns. We talked about various considerations when you actually integrate your infrastructure as code part of your, into your continuous delivery pipeline. But all of that is not just for technology benefits. There are definitely technology benefits that you get out of doing that. But it's also about the people part and the process part. So as you integrate your infrastructure as code as part of your continuous delivery pipeline, you are actually affecting the process that goes on in your organization for putting the code into production. It also affects people, right? Your teams, how they are structured. You should start thinking about how to better collaborate. So as you can see the points over there, it actually enables your team to interact better because now instead of having that security team that is a silo and does things in a siloed way, this actually brings them all together and we'll be showing some diagrams after this to show how that changes once you start integrating your infrastructure as code as part of your continuous delivery pipeline. So yeah, your infrared, your security, compliance, QA, all of those teams work together and then it improves the process like I mentioned earlier and that helps in getting faster feedback. Yeah, so the traditional model and not using infrastructure as code and maybe you are using infrastructure as code and you're not doing it in a way that is continuous delivery. So you could even be using Terraform and publishing infrastructure changes and handing that off then to your compliance team, your security team, somebody who's responsible for confirming that infrastructure works if it's some type of QA team that's QAing your infrastructure. But the thing to point out here though is that it's an inspection. That person is saying this thing is done. They're handing it off to another team who's then inspecting it and if there's a defect in it, it's already too late. That person is pretty much done with the code at this point because they've handed it over the wall, they've handed it off to this other team who will then decide whether or not it can be published and deployed to production. So as you can see, that was the traditional model but now after you integrate your infrastructure as code to your continuous delivery pipeline, you can see that the roles of those teams change. They are actually more enablers and they get involved early on. So the previous diagram here, you can see that they're all involved towards the end right before going to production. Here you can see that they're involved early on. They build the right tools, they automate things and they include it in your continuous delivery pipeline so that the dev team, the infrastructure team who is writing the code can actually validate their changes and they can make sure that there are no security or compliance issues, there is automation so you validate the code that you write. So let me just summarize here what we talked about today. We talked about what is infrastructure as code, we talked about what is continuous delivery and how does a typical continuous delivery pipeline should look, what are the various considerations and best practices that you should be thinking about when you're doing that. And you might be in a process where you are already using infrastructure as code, you already have continuous delivery pipeline but maybe it's not integrated. So you should be thinking about all of these things that are mentioned here, the bullet points when you're doing that. If you have some parts of these missing, if you already have a pipeline and integrated, you should be thinking about those missing pieces as well. And last but not the least, it's not just about technology, it's also about people and process part. So that's our presentation. Thank you everyone for listening and if you have any questions, we'll be around today and tomorrow. So we'll be happy to chat further about any of the things that we mentioned today. Thank you. Thank you.


Look at that place. Sweet. And right when my hand hears it, that's cool. Amazing. That's the nectar of the gods. That tonsil is black, you know, back around.


If you are new to stream deck or maybe you're not but just feel like you could be getting more out of stream deck Then this video is for you Hello, and welcome to take one tech my name's Alec and this is actually take two tech I just started rambling on and I wasn't quite pressed my record button properly or hadn't started recording So yes, this is officially take two. I don't know whether that's going to make it better or worse, but we'll find out So this is the fourth video in a series of videos I'm doing which I've called the beginners guide to stream deck and in video one We took a look at exactly what stream deck is and the various models that are available and video to we looked at how to get started with Setting up stream deck and adding in some basic actions and programming some buttons and Then in video three we looked at how to incorporate some of the plugins to have some more sort of application specific actions and In this video what we're going to look at is how to make all those buttons look pretty and start to actually Do something with them to add in icons and so that is what we're going to get straight into without further ado right now Now if you've watched those other three videos If you haven't I'll leave a link to them in the description But if you have then they should look a little bit familiar because this is sort of where we left off before and What you'll notice is that we've got some different icons on here That have been added in automatically. So these sort of media control buttons automatically have this little volume up and down symbol this one here was switching between headphones and add other speaker output and The built-in one for e-cam live also gives a little preview of the particular scene It's switching to but these two here I've just added in actually are just simple hotkey actions and as you can see it's just a generic symbol It doesn't really tell you exactly what it's doing and because these can be hotkeys They can do literally anything then that's obviously why it's a bit generic because they don't know what you're going to do with it yet So what we want to know is how can we add in icons to these and I did actually Discuss this on one of the previous videos So you already know how to get an icon in there But what I'm really going to focus on in this video is the various different places that you can actually get these icons And how you can get them into your stream deck So first of all, let me talk about the easiest way, which is the built-in Algato way and So up at the top corner here. They have linked to the store There are some icons already built in that will be there when you first start But if I just take you through to the store for a moment as I mentioned on a previous video It's called a store, but it is totally free at the moment for everything that's in there Maybe that will change in the future. I'm not sure given that it's called a store But here on the left hand side You've got a little icon button and so you can click on that and then here you'll see a list of groupings of icons So at the moment you can see that this one says uninstall that's because that little pack of icons has been installed But you can go down and you can have a look through all of these if it's got a big red install button It means it's something that can be added to your stream deck and the ones are to say that say install are already there So come down and have a little look at these There's one there that I haven't got yet. So that is the Photoshop icon pack So this would be a good one to do as a demonstration because I am quite a heavy Photoshop user I've actually got a lot of icons that I made myself for Photoshop before before version 5 came out But I'll have a look in these because dare say there'll be something there Then I haven't got that I'll need so clicking on that you can see this is the Photoshop icon pack and you can have a look It says there are 70 icons in the pack And then I can come back up here and just simply click on install By the way, these are from Sideshow FX. I happen to know that that's a very good resource for other icons I'll talk about that shortly as well, but I'm just going to click on the install button There we go. And that is now installing those little Photoshop icons into my icon library within my stream deck So let me come out of this for a moment That is how we can add the icons in as I say you can just click through these and have a look what other icons there are You've also got some for Premiere Pro. I'll grab those while we're here. So I'll just double click on that single click So now I've got the Premiere Pro icon pack as well And then I will come out of this moved over to one side. In fact so now let's say I was wanting to create a shortcut in here for the Photoshop pack that we've just downloaded what I would do is where the icon is Down here. I would highlight the icon that I want to change and then just simply click this little plus button Which is at the top left once again if you haven't updated to software version 5 then do do that Otherwise this little plus button won't be there and as you can see this opens up the stream deck icon library And what you'll find in here is there are a set of Algato icons the sort of standard ones that come with it one thing to bear in mind is stream deck was in Originally designed for and by streamers so there is quite a heavy sort of live streaming influence in all of the The icons that come as standard, but fortunately you can download these extra ones as well now So if you come down here In fact what I'll do is rather than go through all the Algato ones I'll just little click this little arrow to collapse them and then down here. You'll see That at the bottom we have our Photoshop icon pack. So if I right-click on That then you can see that we've got all of these different Photoshop icons So let's just say I was going to add the brush tool as a shortcut. There we go click on that And now it is added the brush tool To that particular icon So that is how easy it is to grab a set of icons and they do have Photoshop Final Cut Pro Premiere Pro Affinity Designer DaVinci Resolve, which I'm also having a little play around with these days as well So DaVinci Resolve is another icon pack from this same Same producer as well. So that's how easy it is to just go and add in little icons There is another way to do it, which is if you happen to have a Set of icons for example that you've got from somewhere else Or that you've just got an image that you want to use for the icon Then let's say in this particular one. Let's say I wanted to have this icon I've got a little icon file here and I can just drag it over and then that now is become the image So you can just simply drag and drop onto the icons one thing to watch out Is that you do actually drag it onto this bottom area here? Sometimes because it's highlighted it would seem logical that you might be able to just drag it over onto the actual button itself But that doesn't work. It does have to be down to this little area down here So where abouts would you go about getting icons to work just sort of drag and drop onto here? Well, there are a number of places you could certainly do a search on the internet for Streamdeck icons, but I would highly recommend that you actually try to make your own if you've got a little bit of time and You want something quite specific because unless you are for example looking for photoshop icons Then you've also obviously now got those built in But sometimes if you're looking for a particular grouping of icons and you want them to all look the same and consistent and a little bit pretty To have that same look it can be hard sometimes to get a whole group of icons that match and you know Maybe you even want them in your personal favorite colors or company branded colors or whatever it might be It can be hard to get them to match Whereas it is very quick and easy to make them in keynote And I did do a video all about how you can do that and I'll link to that video Down in the description and also up in the top corner as well if I point to the right corner But failing that if you want to actually Buy some icons. There are a number of options for you there as well I do have a store on my website where I have a couple of options So I've got a set of 3000 icons, which is basically it's actually 150 icons in 20 different colors So just to be perfectly clear about that And in fact these are the icons they look something like this So a range of different icons to cover various different things and so yeah You can have a look at those in the the store And then I've also got a specific couple of groups of icons just for some little things that I've also done videos on about How I use stream deck, but I'll link to those videos Down in the description as well But I do mention at the top of my store wait before you buy any icons Do give them a go to actually just create some yourself because it's very easy Now if that does not take your fancy and you've got a more specific use case then I mentioned those icons that were available in the store on the Streamdeck store the store that's free They they were done by Sideshow FX now it's funny because I was actually turned on to this website by Doc Rock on one of his recent live streams in the e-cam community By the way, if you're an e-cam user and you're not in the e-cam live community You're really missing out so much great value in there So I highly recommend that just go to facebook.com Slush groups slash e-cam live great group of people in there all striving to To do the same great things and they're all helping each other out So yeah, you get lots of little tips from there and that is where I find out about this particular website Sideshow FX. This has got a lot of really great Icons for so here you got Ableton live affinity designer after effects audition and all sorts of different applications Very specific sets of icons and as you can see they are just stunning looking and they work for Streamdeck also for loopdeck and for other different Control services that you can get for iPad and and whatnot. So yeah, really really great website I'd highly recommend going and checking those out as well So that is another place that you can go and buy them but do bear in mind. Don't forget to check the store first in The Streamdeck because like these ones adobe illustrator. I've got a feeling that that is the exact same set Or maybe it's maybe there's slightly more in here now. I thought it might be too good to be true So they've got basically around about 70 or 80 that are free in the Streamdeck store But then if you want the complete set then you can get them over here and these are $20 for the for the set for Adobe illustrator So yeah highly recommend highly recommend this site. It's really good for sort of application specific Icons so that's about covers different resources, you know, obviously just searching for them on the internet I'm sure you can find lots as well and so in terms of adding the icons in I've mentioned you can drag and drop you can also Select the file manually by clicking here So going to search on your finder in your finder in your Mac to find them Or you can simply click this open Streamdeck icon library, which is the same thing that little plus key does the one thing I would probably avoid doing is Create new icon that option because what that does is it opens up the Streamdeck icon creator website Speaking as a former web developer This is not a very user friendly website at all and I think you can probably do a lot better with a simple keynote presentation than this the whole User interface of this I think is not good and the design freedom that it gives you is very limited So yeah as a bit of advice, I would probably avoid Of that particular option there But that is how we can get some icons into our Streamdeck and make it looking a little bit more pretty and incidentally if I just come to Show you my profile Of my main Streamdeck the one that I'm actually using this is my setup that I've got at the moment And as you can see there is a sort of consistent look and feel to these And I just made all of these in keynote and it didn't really take me that long once I've got the The the template the layout things like this this little one that looks like a mobile phone. That's just a standard Pictogram in keynote So is the little presentation thing there the little iMac these are all standard things the little camera It's just standard pictograms that you can find in in keynote So that is how I made my icons and then I set up another template and dropped in my application logos to create those So it's really quite Quite straightforward to make icons really and it doesn't take it take that long So I definitely advise giving that a go. Well, that's my little lecture over I hope that you have found that useful if you have found it useful then as always Then don't forget to like and subscribe to the channel and also share this with anybody else Who you think might find it useful as well In the next video I'm going to do a bit more of an in-depth look into the store Basically that they have in the Algato store and just cover all of those different sections that they have I did cover this already in my Version 5 upgrade But I just wanted to include it in this sort of series to touch on some of the things that I haven't talked about with It so far and then that will be almost to the end of our little journey On our beginner's guide to stream deck and then I'll start moving on to some slightly more advanced features that you may want to use and Get away from the sort of little demo screen that I had and show you a little bit more about how I am using stream deck to improve my productivity So those videos are all coming up, but you don't have to wait for those because as ever there's more great videos coming up next Until the next time have a great day


Success for me can mean many things, but I think it's about fulfilling one's own personal endeavours and doing the best that you can. For me and my career, success for me was about having a professional career, trying to be a good artist, to be able to create work that I wanted to create as a choreographer. And now as a NTC director, it's about me sort of supporting and mentoring my dancers that I'm working with to make sure that they can feel their job to the best of their abilities. Three, four, yeah. And then I'm starting to do the travel. Yeah, then it's going to go right, swing right. Left, right. Do you flow with them? Move with them. Five, six, ready, sunshine? Yeah. One, two, three, four, hold five, five, right. Six, seven, seven.


Good afternoon everyone and welcome. This is Melissa Armel of the Stocks. What's in here reviewing the spy? Why did it go over this today? Why? Because of the fact that the market is still higher. I know everyone again thinks that we're lower because of the fact that the the body of the day of today right now at 1258 has a red in it but but do you see here we're not going anywhere down. I mean we're not going anywhere down and we're not gonna go anywhere down and actually well we didn't get over yesterday's high but we almost did. We almost did. The queues are really lagging. The queues of the lager but we were green in the day at one point. Open was 198.79 and went 20 cents over it and then came in a smidgen but this is like a baby smidgen. I thought 12 o'clock we have to hold by. Let's just see where the low of the day was so far. This is the low of the day in the market. Very very very tricky and I thought yesterday was tricky to call. Today was even more tricky to call. Even more tricky to call because we really should have rallied immediately this morning. We couldn't do it. I don't know why the queues is lagging. It doesn't even matter. It's lagging behind but eventually all these things will blow. They could blow today. They could blow tomorrow. It's gonna do it. It's gonna do it because once we get over 250 and get positive on the year we're gonna run and here is the level and we're not even that far away from there. So it's like we're just a matter of time. So anybody that's showing this market today is it's crazy in my opinion because it's not falling and again I know how to read weakness. This isn't it because if this wanted to drop it would just collapse into support. I mean we have rallied here for two days. If this wanted to drop we just collapsed into support and we did gap down today. It was not a big gap down but we actually did gap down today but look how well we're holding. So we could break out today at 2 o'clock or 3 o'clock and run into the close and run right up into 200 a dollar over the high. That's all it would be. That's all it would be really. That's all it actually would even be would even be less than two dollars move of the day. So and then we then here here's prediction. So we either just go like this the rest of the day and never drop and never go higher or we rally over 199 over yesterday's high rally up somewhere around 2 o'clock or 3 o'clock rally into the close rally up into 200 250 and then we then we gap up tomorrow and then that's what we do. And there you have it. This is Melissa with the Stock Swoosh. Have a great day everyone. Email me at Melissa at thestockswoosh.com if you want more information. Don't short this bucket. Don't short the market. Don't do it. We're higher and we're getting ready to blow. And I don't know when. It could be today. It could be tomorrow. It's either gonna be today or tomorrow that I can tell you. Have a great day everyone. Email me if you want to sign up for the Golden Gat class. It's this weekend Saturday and Monday. You can go along the market right here. And because this actually could blow right here. But the problem is you have to put stop under 198. So it's a big stop. Have a good day everyone.


One of my friends offered to give me this book and I was like of course I love Shakespeare already and you know I'm into free will. The Netflix series 13 Reasons Why based on the book of the same name tells the story of a teenage girl Hannah who is recorded a series of cassette tapes blaming various individuals in her life for her eventual suicide and releasing the tapes after her death as a form of punishment. The show has been in the news for prompting a few troubled teens to end their own lives. It's currently preceded by a content warning asking viewers who might be at risk to seek counseling if they experience suicidal ideation or need support. However the way that the story is told doesn't always paint Hannah or her reasons in a very positive light. One might even get the impression that there's a fair amount of contextual criticism of her character. There are numerous points in the narrative where her account of events is revealed to be exaggerated or even outright fabrication. The grievances she cites are sometimes made against a backdrop of other characters who are enduring similar difficulties and dealing with them in healthier ways. At points the viewer is reminded of the fact that despite her setbacks Hannah has a number of advantages that many her age do not like invested parents and peers who care about her. A viewer might accept Hannah's reasons at face value, but one might also get the impression that she's blowing these events vastly out of proportion and that her unhealthy outlook is far more to blame than the circumstances she's citing. What sticks out the most to me about either way of viewing the story is a theme of unavoidability. Hannah's tapes lay the blame for her suicide at the feet of others, essentially saying these individuals and their actions have caused me to take my own life. Any other person in my situation would make the same choice. Alternately, the show itself might be seen to suggest that Hannah, her seemingly pathological interpretation of events and her inability to cope are really to blame. That it really wouldn't have mattered if her classmates had been a little bit nicer to her. She'd still find her reasons regardless. I feel that both views are incomplete in an important way. A long ways back I gave the most bare bones of descriptions of compatibilism, the predominant philosophical theory regarding the question of whether humans have free will. That is, whether we exercise some sort of meaningful control over our choices and actions, or if they are primarily determined by external factors. In short, there seems to be a conflict between our subjective experience of our choices, the feeling like we're calling the shots, and various facts we observe about the world, things like cause and effect, or the decidedly predictable ways that manipulating a person's environment can affect their decisions. We feel in charge, but there are good reasons to suspect that that's not the case. Compatibilism asserts that we actually don't have to choose either a deterministic view of human psychology or free will. That the most coherent explanation of what we observe includes both positions. Yes, there are important differences between a person who's acting according to their own agency and a person who's being controlled or coerced. Yes, human decisions are the result of a chain of causation and can't be siloed off from that causal chain or the rules by which it operates. We can, usually, choose our own actions freely, as constrained by the laws of psychology and physics. Viewed this way, trying to draw a box around Hannah's mental state or the cumulative effect of the individuals she blames for her suicide and saying, here, here is the reason for Hannah's death is a misguided enterprise. Hannah's action is the result of a long series of causes and effects, both internal and external to her person. It's true that if she had been bullied less, she might have made a different decision. It's true that if she had learned better coping skills, she might have made a different decision. It's true that if she'd worked harder to find a healthy outlet for her frustration, or if she'd read something helpful at the right time, or if she'd been unable to find a blade, or if she'd been lightly mauled by a koala bear and hospitalized, or if any number of other links in the chain of events leading to her death had changed in some way, the outcome might also have changed. And it's true that, ultimately, the final choice was hers. It's not just impossible to attribute the event to a single step in that process. It's dangerously myopic. The National Association of School Psychologists has issued a statement about 13 reasons why, suggesting that it's not simply a risky piece of media to show to high school students who might be especially vulnerable, but that it totally avoids discussing the prominent role of treatable mental illness in suicide, and thus reinforces the most harmful message imaginable, that suicide is the only response to a sufficiently bad situation, that the causal chain of bullying and abuse can only end one way. Therapy or medication might well have been the things that ended up putting her on a different path. The integrative way of looking at Hannah's decision through the lens of compatibilism paints a much more nuanced and practically useful picture, both for policymakers who are trying to prevent suicide and for individuals who may find themselves at risk, as many of us are. Rather than narrowly focusing on stamping out bullying or toughening people up as the sole mechanisms of prevention, it highlights every step in the process as a potential turning point, a place where the right input can cause a much different result, and grants a sort of recursive agency, a chance to make decisions that can affect our future decisions in reliable ways. For example, choosing to exercise at a particular day doesn't feel that important in the grand scheme of things, but physical fitness plays an important part in maintaining mental health, and people who exercise regularly are significantly less likely to commit suicide. This makes the choice to exercise a potential breaking point in the chain of causality that leads to suicide, a fork in the road that may well lead somewhere better.   Now, to be fair, I can imagine someone agreeing with his overall sentiment, and then simply focusing on whatever part of the equation they find most compelling. Because, hey, every part of the causal chain matters, right? It's important to recognize that there are variables that have lesser and greater effects, which can and should be evaluated using statistical methods, informing what we focus on most. Some individuals will appeal to a naive, holistic view of human behavior knowing this, either to prioritize or minimize some factor that's important for their agenda. Yes, yes, we have to teach better coping skills, but every part of the process is important, so let's talk about something else. Still, viewing human decisions and behaviors in a compatibilist framework as choices made freely under deterministic rules can liberate us from a narrow-minded focus on singular aspects of that process. Hannah comes up with 13 fairly uninspired reasons motivating her decision, but there are literally thousands, everything from her diet to the fundamental physical consonants of the universe. If she had been thinking of her future decisions as deterministic consequences of her present ones, maybe she could have made better choices. Can you think of a decision that you've made that has had significant consequences for a later one? Please leave a comment below and let me know what you think. Thank you very much for watching. Don't forget to blah, blah, subscribe, blah, share, and don't stop thunking. Good boy.


ntor, which was very, very helpful. And from which I learned a lot. If you want to learn more about QCF or contributed project, you can visit the repository on GitHub. And if you want to see my work and the files from this project on the MFM project, you can visit the GitHub repository on the screen. Thank you. Awesome. Thank you, Dan. Great, great project and great to see contributions to Cloud Foundry to help support the mainframe even more. Moving ahead here, we have Matish Goplani. Matish, if you want to jump in here, then we have two more presentations after Matish. Matish, are you able to present? I think you're having some audio problems. We can barely hear you. It's getting better. Hello. There we go. There's a little bit of static. Hello. Can you hear me now? I can. There's a little bit of background sound, but it seems to be okay at the moment. Is it fine? Hello. Yeah, I think this works. Can you hear us? Yeah. Hello. Awesome. Go ahead and do your presentation. All right. Hello, everyone. This is Matish Goplani. And today I'm going to present about my work, which I did as a part of OMP mentorship on Zoe desktop application state persistence mechanism. A brief background about myself. So I'm currently working as a software engineer at JPMorgan Chase. And I'm also very interested in computer security. I have been certified as an OSCP OSC and OSW. These are some cool certifications from offensive security. And I pursued my computer science from Umber University. And I was also a principal developer and maintainer of an app called med student, which was previously known as health savvy app. And I have co-authored a paper titled animate object detection and key ground control. So why did I choose this project state persistence mechanism was an interested project provided by Zoe, which required the developer to be well versed with internal working of Zoe. And also provided an opportunity to contribute to a project that would be consumed by many Zoe apps to process their statesman session expires. So I thought my experience with web development and Angular along with a bit of a security background would really help with the development of state persistence mechanism for Zoe desktop considering the security aspect of the methodology involved. So what was this project all about? As you all know, Zoe has a lot of Zoe is an application framework where a lot of plugins run on top of it. So when plugins running within the application framework did not have access to a secure state persistence mechanism that would allow them to restore their state on the next session login. So the idea was to develop a state persistence mechanism which would allow Zoe applications to be able to save their states at Zoe desktop storage and persisted the next time they'll try to log. So these last state of that gets restored automatically. This is a quick overview of how this system was developed. We start with these applications. So we had two types of applications on Zoe desktop. The first one was normal desktop applications. The other one were single page applications. So these applications would send the data which they want to save to components such as window manager and simple window manager at regular time intervals. This time interval is considerable according to the requirement of user depending on the time interval these apps would constantly keep on constantly send data to window manager and simple window manager which would in turn send this data to desktop plugins or desktop storage. So these this data is saved separately depending considering the authentication of the user. So we have two different storages. One is for one is app based storage which is for desktop applications. One is single app storage which is for single page applications. On the next login attempt authentication manager would try to retrieve those application data on its own from desktop storage and would spawn applications with those data. So consider a scenario where you're working on something really important and you forget to save up. So either a browser crashes or you log off or a session expires or something like that. So this mechanism would help you to retrieve back to the last state depending on what was saved on the Zoe desktop. So I got done with this project a bit early in the course of my internship. So I went ahead and took some other projects. So a quick overview of what those projects were. So those are basically focused on improvements on zealux editor. The first project was that restore mechanism where we keep a track of all the open tabs zealux editor and restore them on next launch. So this is a bit different from what we did in state persistence mechanism because in this case we are using editor storage not desktop storage. So this is specific to zealux editor and enhancement to the current working of zealux editor. We also added copy and cut operations to zealux file explorer which is embedded in zealux editor. This project, why this project got completed. This would support only us but there are plans in future to also support NBS, which are data. These are some of the links to the links to my work links to my PR these this is more related to state persistence mechanism, which was my main project. This is for tab restore part and this is for copy and cut operations. This is a general work which I did. All my work is has been documented and saved on this GitHub repository Zoe desktop application state persistence mechanism. If you go to this documentation folder, you will have a you will find a very detailed demo video of the actual working of the system in notes and research you'll find an architecture diagram which is a bit more detailed. And the entire link to the source code is there in the src repository. If you're interested in this project, please do check it to check this out. And that's it from my side. Thank you so much for listening to me. Awesome. Thank you so much. Great presentation there and great. Great seeing those contributions into the community. So we have two presentations left. So zoo. If you want to pop up next and then we have guys here on video. Okay. Awesome whenever you're ready. All right. Hello everyone. My name is Salis Ali. I am one of the main case for MP mentorship 2020 program. Together with my mentor Alex Kim, we were able to work on the project. So we smf stroke arm a person engine, which we like to call zebra. So a little about me. My name is Salis Ali. Like I mentioned, I'm a 40 a medical student at Byron West T canoe Nigeria. I'm a software programmer. I started learning programming in 2016. So I participated in IBM master the mainframe for the year 2017 2018 and 2019. And luckily for me in 2017, I emerged as the regional winner for Middle East, Middle East and Africa. So I like to put my efforts into learning and getting certified in mainframes, IoT, machine learning, Android and the cloud. I also like building projects on my own, especially when they are related to smart home and telemedicine. So I applied for MP mentorship to get real world real world experience in developing software for the mainframe and also to build on what I have learned already from master the mainframe. So in 2019, the final challenge for master the mainframe was on syslog, syslog. So when I saw another project related to system logs, I decided to apply for it to that's for the RMF side. So this is a brief description about the project. So Zoe, as we know, is a great system operations tool. So one of the system programmers offer performance analyzers job is to decode SMF stroke RMF report to check systems health. So if you can create a generic parser for SMF data set or RMF, this will give this analysts an opportunity to create and reuse many open source monitoring tools out there. This will really make their job easier. So this is the project architecture. As we can see everything starts with a user's request. When a user sends a request to zebra zebra will now for the request to RMF DDS server through HTTP API gateway for RMF. Then RMF will now return an XML file. This XML file will now be passed in zebra. This RMF, this XML file will not be converted into JSON format. So at this point, the JSON format can be returned to the user through Zoe API catalog or through the browser. And at the same time, we took some time to convert this JSON format into what we call custom primitives metrics, which are then stored into primitive server. Prometheus hours users can now connect to Grafana and plot real time graphs. I don't want to interrupt you. I don't know. You're not sharing your slides. If you are talking to slides right now. Okay, I'm so sorry. No, no worries. No worries. We were you were talking great and we were just trying to follow along. So I apologize. Also, can you see my screen now? Yes, we can. Welcome to Grafana. Yeah, perfect. Let me get started again. Also, hello, everyone. My name is Salis Ali. I am one of them in tasteful or MP mentorship program 2020 together with my mentor Alex Kim. We work on the project SMF as a SMF stroke RMF passing engine, which we like to call zebra. Tell about me. As I mentioned, my name is Salis Ali. I'm a 40 a medical student at Byron West T Cano Nigeria. I'm a software programmer. I started programming and I started programming in 2016. I like putting my efforts into learning and getting certified in mainframes, IoT, machine learning, Android and the cloud. I also like building projects during my spare time, which are related to smart home and telemedicine. I applied for MP mentorship to get real world experience. This experience has to do with developing software on mainframes and also to build on the knowledge I have already gotten from master the mainframe. So, as we all know, Zoe is a great system operations tool, and one of system programmers of performance analysis job is to decode this SMF stroke RMF report to check systems health. So if we can create a generic pass up for SMF data set RMF users can now have the opportunity to create stroke reuse many open source monitoring tools out there. So this is the project architecture. Everything starts with the user's request whenever user sends a request to zebra. This request is now forwarded to RMF DDS server. The RMF DDS server process this report and return an XML file. This XML file is then converted to JSON. This JSON data can now be returned to the user through the Zoe API catalog or through the browser. The same JSON data that we have converted from the XML can be stored into Prometheus server. And then from Prometheus server the user can connect to Grafana. Another use case we made use of is converting our saving this JSON data into MongoDB. So the project use case, the projects have about five use cases. We have passing RMF monitor three report to JSON. We also have passing RMF monitor one report to JSON. We have passing RMF static XML file to JSON. Then we have saving RMF monitor three report to MongoDB. And finally plotting RMF real time metrics with Grafana. So how can users access data through zebra? The first option is to use RESTful API directly to zebra. This one can be done using the browser call or postman. Users can also make use of Zoe API mediation layer through the API catalog to access this JSON data. And then through the MongoDB, if data has already been stored, users can use command prompt or MongoDB compass to access this data. And then we have graphical data access. This is mostly through Grafana. And then the recent one for by my mentor use Viva to actually access this data directly to his phone. So at this point, I would like to show us a demo, a simple demo on how zebra present this data to user. The first one is the browser user need to just get in my own case, I'm running this zebra local host on my body is 3090. So we have specific endpoints. This endpoint is for RMF monitor three. In this case, I'm requesting for CPC reports. So let me try to do that again. Yes, this is the updated reports. This is the eastern time. I believe it is 10, 10 a.m. now. And then there are other reports to like usage or proc reports. All this can be done through the browser. This is for RMF monitor three. There's also RMF monitor two, RMF monitor three, sorry, RMF monitor one, and then the static XMF. But for the sake of time, I would just like to move to API mediation layer. As we can see, I'm also running API mediation layer locally on my system. We have already embodied zebra to API mediation layer using simple on body without any code change. This is zebra. And then we have the set of APIs. This is from the swagger definition we have provided. In this case, all I need to do is execute this. This now returns reports. In this case, I'm using one of filters. We have also provided filters. In this case, I am not requesting for the whole report. I just want to get this CPC HMSU value, which is 365 in this case. So there are also other APIs that users can test. Like in this case, I will now request for the complete CPC report. This now returns the complete CPC report. Then moving to Grafana. As we can see, I've already built some dashboards. These are simple dashboards that I build using zebra. There are some procedures that have to be followed like creating a data source. And then finally creating a panel to get this chart. But all this have been provided in the user documentation. So I will not be going through it. I would not like to move back to these slides. So finally, the progress made where we were able to zebra have provided flexibility for users. Users can configure this app to make use of it to their own needs. So for this configuration, the configuration can be done using REST APIs. So we try to secure this REST APIs using Java Web tokens. Then we have conversion of RMF monitor 3 XML report to JSON. We have conversion of RMF monitor 1 CPC and workload reports to JSON. And then we have importation and conversion of RMF monitor 1 CPU and workload XML static files to JSON. And then we have saving RMF monitor 3 data to MongoDB. And then finally exporting custom metrics to Prometheus. And then finally plotting real-time charts using Grafana. So lessons learned. Actually, as I have mentioned earlier, I'm a medical student, but I've learned a lot through this mentorship when it comes to software development. For the first thing, my proposal was likely garbage, but my mentor was able to send me down and show me how to write a good project plan. What do you look for when writing a project plan? And then he also state design thinking sessions where I've learned a lot. And then working as a team, as a medical student, I normally work alone when I want to program, because I don't have friends that do that around me. So I normally work alone, but during this mentorship, I learned so the experience is when experience is brought into team, great things can be achieved like my mentor has 20 years of experience. So that has speed up the development of this app and then the energy. So when we have to achieve something, we don't care, we spend the time needed to achieve that. And even if it is during the weekends, we don't normally work on weekends, but when there is need, we put in that energy to work on the weekend. Then collaboration. When we have issues, we collaborate with other teams like Diso API, Mediation Layer to get this running on our local host. And then finally tools. I've learned tools like how to use tools like GitHub, Trilo, Docker, and Linux. And then finally, the project can be found at this URL. And then finally, I would like to say thank you to MP for giving me this opportunity and thank you to my mentor for taking all the time to support me through this journey. Thank you. Thank you all. Thank you. Definitely appreciate your presentation and all of your work there and apologies for the technical difficulties. So we have one more, which I'm going to do real quick here. We have a video from Kai and I'm going to try to share my screen with that. Let's see if this goes. Oh, if you could stop sharing your screen. I'm trying to do that. Oh, stop sharing. There we go. All right. No worries. No worries. All right. And we're going to try to share the sound here. So we'll see how this goes. This may not work. All right, let's see if this works here. I'm going to start playing it. And we'll go from there. Hi, everyone. I'm Kai Wong. I am a software engineering junior student from Beijing Institute of Technology, and an open source lover. I had experiments in multi programming languages like C, Java, Go, JavaScript, Python, and Rust. I love trying new stuff and making fantastic projects. During my freshman year, I was a student participant of Alibaba Summer of Co. 2019 and wrote an online GUI designer for early OS things. Now I am a mentee of the open main thing, mentorship program. I am also maintaining a pool of our thing written in Go, which is an open source project of Tsinghua University Tuna Association. I am in 50 S in open source, I think the mentorship put me a really good chance to learn about all some open source project and experience modern and formal development. Without the mentorship, it's impossible to share my idea and code all over the world. Main thing has transformed it over the past 65 years and still is the go-to platform for high, transactional and secure computing. Before the mentorship, I didn't know much about main thing. This mentorship opportunity for Linux foundation will surely improve my skill about main thing. What's more, during the COVID-19 pandemic, the mentorship provide me with the opportunity to work remote so I can stay at home. Javier Prometheus is not maintaining anymore. Feilong is an open source Javier and CalConnector project. It provides an easy way to manage Javier. It's suitable to improve Javier Prometheus. My project is to write a new Prometheus is portal for Javier mattress based on Feilong. Now I just released the second version of this portal. It's available on the Python package index. And you can install Javier Feilong's portal via the Python package installer. Before the mentorship, I had no clue what the main thing is or that is even existing. I became a main thing software development in the mentorship. The most important thing, I learned the coding and software architecture skills in the mentorship. Thank you for watching. Awesome. Thank you, Kai, for that great presentation. And I want to thank all of you. Watching this, I want to thank all of you mentees. You've done amazing work and made great contributions to the open source ecosystem and mainframe. You can check out more of the links that they provided. They'll also be around the conference here all week. Go reach out, meet them, and connect with them as well. Thank you all. And have a great rest of open source summit Europe. Thanks, John. Thank you all for presenting today. And just for everyone who's an attendee, remember the videos will be up on YouTube here very soon. Thank you all very much.