 Hi, everybody. Welcome back to another technical demo around the Quarkus application. I am Daniel Oh. So for several years, Kubernetes has turned into the foundation layer of cloud-name application architecture to run microservice applications and serverless. But they also changed significantly for developers to control the inner and outer loop development workflows of Kubernetes at scale and speed. What capabilities are required in the application framework to build code and automating deployment quickly in line with the developer loop, and what benefits will developers gain from it? In this demo, I'm going to walk you through how Quarkus allows you to enhance the developer loop by live coding on the remote or push of the cluster, just like what you do in your local environment. Let's get started. OK, so we're going to use the Maven plug-in command line to generate the Quarkus application. As you can see, we need to specify a project group ID and an artifact ID and a project version. In a crash-name, real resources will be generated automatically to explore the RESTful API. And also, we're going to use a project extension, which allows you to generate all applications to manifest to deploy your application to remote or push-to-container platform. Once the build succeeds, let's try to take a look at that. The new project is actually just generated, and I tried to open this project with the Java editor, such as VS Code. And when you go to Palm XML, you can find all the dependencies already pulled down in your local environment, like for example, Quarkus or push-to-extension already pulled down. When you go to Gradle source, the Java file, which exposes REST endpoint, and just hello or return code, hello, REST easy, OK, go to change directory, and try to run this application as a Quarkus Dev mode. So you can actually run this application with the live coding capability on your local machine, which means whenever you change code, the Quarkus automatically detects the changing code and the re-packaging reveal, and redeploy it as hotspot technology without any human innovation. As you can see, the profile is activated and the live coding activated. So cool. So let's go to web browser and try to access the endpoint, like hello. And then we're going to find the end code, hello, REST easy, you can see that. And then the next move, we're going to change the code just like imagine, OK, I need to change my application, like a return output, hello, REST easy from local, and try to replace your web browser one more time, and you can find that the new output will be showcased. It's pretty simple, and this is how you change your code and the live coding. So hard to see the Quarkus automatically detects the changing code and how it replace to your code. It just took one second to make it happen. Pretty cool, isn't it? So I'm going to stop my local environment, and I need to deploy this application to open up the container platform. In order to do that, I need to package this immutable application because we need to steal live coding functionality when you deploy this application to open SHIFT. So even though this application will be containerized, but still this application mutable, which means we can change the application code. And then the library load password should be communicate between client and server. You can put in any random text. And then here are some configuration to deploy this application to open SHIFT, like a container image build. And we're going to use a client trust certificate on a container platform and target environment when it's clustered, definitely open SHIFT, and then we're going to explore this application using opposite route capability. And then there are one in bottom valuable to use live coding that mode. So this is my opposite container platform, but there's no resources here. So I'm going to need to make sure I already logged in this project. So using OC command line, OK, I'm here. And then we're going to use the main command line once again using main packaging. But we needed to pass down quark-curse-cuban-s-deploy equal-true, which means once your mutable application is packaged and then opposite the source to image processor will be triggered to deploy this application to open SHIFT container platform. In the meantime, this process will containerize this application to reduce container image and push it into inside the opposite container registry. OK, build success. And then let's try to a little bit drill down target tree. And then you can find the quark-desh app. It's a new directory that are putting your mutable application. For example, quark-station-run.job-file is the mutable application. OK, so application is deployed in opposite container platform. When you click on this part, and then you can find the view logs. And then here are the view logs. And you can find profile that activated in live coding activated just like a result in our local environment. So it means that you are all set to ready to go to use live coding. Try to access and pulling on opposite container platform. Hello, let's easy from local. That's exactly the same thing you say in output we saw in the local environment. All right, just copy the URL. And then let's try to run local environment with remote development. In order to that, we need to add one more configuration such as the live load URL, which refers to our raw URL. And then we don't need to dis-publish the configuration because we don't need to trigger OpenSYB, the process of whenever we change code. OK, try to run quark-station-remote-desh app, which allows you to run quark-station application as the remote demo, which means your quark-station-run time tries to access the remote server that can connect to the remote server based on the remote URL. OK, so pretty cool. And the next step, let's go back to our application code and change the output from OpenShift. And then go back to our web browser. Try to refresh this web browser. And then we've got to have a new output. Hello, let's easy from OpenShift. Just like the same functionality we did in local environment. Behind the scene, the quark-station-remote-desh environment actually tactic the change in the code, grid-resource-double-classes, and then try to send the application-classes-and-jar, mutable-jar, to OpenShift container platform. Let's try to one more time just to have fun. And then with the quark-station-remote-desh, and then reload web browser once again. And then we've got a new output here. Pretty easy and pretty cool. OK, so today in the demo, you learn how quark-station-remote-desh is capable of enhancing the developed loop by activating the live encoding capability from your local machine to the remote container environment, for example, OpenShift. But also, you can actually run this capability and vanilla capabilities in a container engine, et cetera. So this is what new cloud-native job runtime should provide for developers to simplify the development of workflow from writing code to build, run, devote, and deploy Microsoft's and software's application at speed. But just be sure you don't need to use this functionality in your production environment, because it might cause unexpected functional changes immediately or while you are running the remote demo. Thank you for watching. Please make sure to subscribe to this YouTube channel and have a good rest of the day.