 It looks like we're live. All right, what we're going to do is screen share, jump right into this. We need to share the desktop, here we go. Okay, we have a lot of ground to cover in a very short period of time. Hopefully you guys are ready for a wild and fast ride. We're going to be talking about reactive programming and we're going to show you a lot of really cool demonstrations of a technology called VertX. And actually I have a ton running here on my desktop already. We're going to get a chance to play some games together, look at some interactive content. And do note that the chat is over here, but I won't be able to see it too easily. Please do ask questions via the chat though, and I'll get to it when I can. We'll break out into demo mode. Do look at the slides. The URL for the slide deck is actually right here. At Bitly, going reactive Java, that'll get you right into the live deck and then you can actually follow along from a slide standpoint and feel free. It's a Google Doc to fork it, take it on your own and run away with it. My Twitter handle is there as well as my email address. Feel free to email me, hit me on Twitter. Anyway, you would want to communicate with me. Okay, let's dive right in. The first thing to realize is that this is a brand new show that we're now launching as of today. It is known as Day of Nation Live as a tech talk. We're going to basically spend about 30 minutes together on a reoccurring basis, the first and third Thursday at noon. So the first and third Thursday every month, we're going to try to bring something new and cool for you guys. So this is episode number one and we're going to show you a bunch of really cool reactive programming concepts and reactive programming demos to get it so you guys get a feel for where we're going from a vertex standpoint. But in the second episode, we're going to dive right into Kubernetes and spend a lot of time with what it means to build Docker based containers to run on the Kubernetes backbone. That'll be super awesome. And Rothfield does a great job offering a workshop around that concept. The third episode, we're going to actually show you something pretty futuristic around the concept of a project called Istio and Envoy where you actually build side cars to add to your pods and Kubernetes and you can build on microservices mesh and Christian Post has been doing a lot of R&D work on that for us. And then we're going to show you some big data stuff. So you can see Apache Spark within Finispan. That'll be super awesome with Galder. And then we're going to do another deep dive into products and reactive overall with Clamont who actually wrote our first book on this topic. So there's a lot more coming and we're going to be scheduling numerous rock stars from presentation standpoint and numerous topics as we get going here. Now there's a book available on the topic that we're going to be focused on today. So if you go to developers.red.com or if you join the slide deck, you'll find this is a link or this is a link and you can download this book and actually walk through some of this content more slowly. So feel free to download that book and get started but go ahead and pay attention right now. Don't start your reading just yet. Now, I often like to start my presentations with the concept of the evolution meaning that we're always evolving, we're always moving forward as developers because in the 70s as a developer, all we had to learn was COBOL or JCL or WFL. That's all we really had access to or all we had to know from a developer standpoint. We worked on a mainframe whether it be UNISIS or COBOL and in my case, I was more UNISIS. So I had, I used WFL, right? I was not so cool. I didn't couldn't do JCL back then. Workflow language is what WFL stood for. But in the 80s, we picked up things like C, C++ those become much more dominant in the overall business application space. 4GLs also started coming on the scene whether it be progress or focus or Ingress all back then. And I don't know if you guys remembered Netware but I was actually a Netware administrator. I know that's kind of old school for some of you guys but yeah, that's where I was. And of course, relational database and SQL was kind of born in that era. In the 90s, we started picking up things around the web. HTTP, HTML, you can learn HTML in three days by reading Laura Lame's book. I did that back in the mid 90s and we learned the CGI, you know, Common Gateway Interface and get and post. We learned about cookies. And of course, cookies were terrifying back in the mid 90s. I don't know if you guys remember that but I used to have to explain to users that a cookie was not going to steal their identity. A cookie was just like an ear tag on Anlope. And if they were watching Mutual Boomahal's Wild Kingdom, they would understand what that meant. But then I learned most people didn't actually watch Mutual Boomahal's Wild Kingdom in the 80s like I did. So just keep that in mind. Cookies can be a little terrifying for some people. And as you go into the OOs, right? You would see things like MVC, right? The Struts, DI, Spring, Hibernate, all those cool things came on board. We did a lot of XML. We did a lot of SOA and web services. But really, in the modern era, we're now having to learn things like Angular, React. Maybe we have to do mobile, iOS and Android. We might learn Maven and Gradle. Now we're learning Get. Instead of Subversion is a good example. But my point with this whole presentation, this whole part of the presentation, is that Reactive is just yet one more skill that you're starting to pick up on now. So just one more skill, one more tool in the toolbox. And of course, our ultimate mission is to all be like the GitHub rainbow unicorn here. I love that guy, but the mythical beast. Let's keep going. So let's define Reactive. There's two forms of Reactive out there in the world. Reactive programming and Reactive systems. That's how people think of it. Or at least they should be thinking of it. There's Reactive programming, meaning how do you write syntax that actually demonstrates Reactive properties? And then of course, how do you build a Reactive system? So let's kind of break those down. The good news is you can just relax the use to go in either category. And then it all should be noted that a Reactive system does not necessarily have to be based on Reactive programming. Though obviously that does help you. Reactive programming is programming with asynchronous data streams. So I really like this definition. And it's out there. Here's the URL for it. Because that is really how you should be thinking of it. In a world where everything is async and ongoing and it's never ending, right? The data stream is just constantly coming at you. And one of the demos I'll often do is actually an IoT demo where I show sensor streaming because your temperature sensors and other sensors out there in a while, they have no concept of you're overwhelmed. They just keep sending out their data. And it's kind of like you tuning into a radio station. You basically tune into the radio station and you get the stream. If you tune out of the radio station or off the radio station, you don't get the stream. The radio station does not care that you're paying attention or not paying attention. They're just gonna keep sending the data your way. And it's up to you to manage that asynchronously and buffer it accordingly. So Reactive programming and asynchronous data streams is super important. Now this is where we break into reactive systems. So not necessarily programming. So in a reactive systems world, this was defined by the reactive manifesto. You can read about it on the internet there with the URL. And the key component of that is it's message driven. Some people would say event driven. The idea being that it's going to be asynchronously invoked. And you can think of these messages flowing independent packets as flowing through those streams. So by default, here comes my stream. Here comes a message. Is it right here? Okay. I have a lot of things running. And I'm actually running this in the public cloud. So you guys are free to join me. And if you actually look at this URL right here, it's gonna be live here momentarily. So the first thing I'm gonna do is I'm gonna run a standard Spring Boot application. We'll show you the code for this in a second. But let's just run a simple Spring Boot application. I'm launching it up again in a public cloud instance with the main name as web.bird.red. But this is running on 8080. Just keep that in mind. We'll switch that in a second. But there's my Spring Boot application, okay? It's real super simple. It's kind of like Hello World, but we call it Goodbye because we're gonna actually injure it a little bit. So by default, if you guys are clicking away on this also, you'll see that it's just responding nicely to the user. But what happens when we pound on it? So this little guy down here generates 51 requests to this bigger application. And I did change the thread pool on Spring Boot to be 25. So in other words, there's more requests, more users, than there are actually threads to respond to that user. And you can see right now, it just locks up. It's no longer responsive until of course the thread becomes available. And then if I hit refresh here, you can see it's now locked up again. So the whole concept that we've had in JavaE World, right, whether it be Tomcat or traditional JavaE is that by default, it assumes a thread per request. And that's just the model it's in. But if you use all the threads, then you can't handle any more requests. So now you can see that our threads are completed and we're back to working again. And I don't want you to think that I'm actually picking on poor Spring and Tomcat here. Here's our application, right? So the Wildfly application server also based on Wildfly Swarm, Wildfly Swarm takes the application server and allows you to break it apart into a fat jar architecture, a bunch like Spring Boot, or a bunch like Drop Wizard. In this case, I'll run Wildfly Swarm. And so if you're refreshing with me now, you'll notice that I took the server down and it's now coming back up here. But here we go. So there we go, right? We got the Wildfly Swarm up again. Oh, I got messages flowing in here. Says I'm not sharing. Let's see if I am sharing. All right, so we'll reshare. Dun, dun, dun, dun, dun, dun, dun, dun, dun, dun, dun, dun, dun. Okay, retry. It says, screen sharing, filled to start. Okay, mm-hmm, mm-hmm, all right. Well, I'm not sure how to get the screen sharing to restart, it says it will not start. Let me see if I am, I'm gonna have to refresh this browser window here on Google Hangouts and we'll see what happens, okay. Back to sharing. Okay, we should be sharing again. There we go. All right, if you guys need me, just ping me. But there we go, let me see, bring up these little windows again, back to it. All right, where did my little windows go? Okay, so we just brought up Wildfly, as you can see here. All right, so the same thing as before as the Spring Boot application. But again, the same kind of concept. If I hit it with overwhelming load, we're going to be in a situation where it basically pauses or hangs based on the fact there's 25 threads to process user request, but there's 51 requests coming in simultaneously. And so whenever, again, you have a thread per request model, like we do in traditional Java applications, you will eventually run out of the gas and then your users will wait. They can cancel that transaction by hitting X here and refreshing, all that does is send you another transaction that you cannot handle and just, of course, there's no one listening anymore to respond to that. All right, so now we're back to good again. So that is it from a Wildfly swarm standpoint in Spring Boot, but let me show you VertX, okay? Let's go ahead and get started. Let's get the VertX system started. So VertX, of course, is an asynchronous, pure reactive system, and I'll show you the code behind us in a second. Let's go ahead and get it started. Okay, you can see it starts super fast and I can refresh, refresh. And again, you guys can use that public URL there also. But if I go, let me run the command line again. Again, we're gonna send in a bunch of requests and you can see the requests are going in, right? So they're all in there pounding away at the system and then, but I can still get my responses. So the user is not hung up. He or she is still gonna get responded even though that the system is totally overwhelmed with load right now. So even though all 25 threads are being used, right? The foreground thread, the thing responding to users is always available and that's known as the event loop. We're gonna see more of that in a second. Okay, all right, so just keep that in mind that that's the concept of a reactive system. Let's jump back into here. All right, and we'll go here. Okay, so reactive systems. Now, let's talk quickly about microservices. It looks like a lot of people have joined my slide deck. That's good. Now, in a microservices world, you have to think about this entire evolutionary process, microservices being at the end point of this evolutionary process of DevOps, self-source on demand, elastic infrastructure. These are all critical components. So think about these things as we get there. We're gonna dive into more of these topics as we go throughout this definition live series. But today I'm gonna really focus more on the microservices side of it as if you're already at the end game and how do you use a reactive system like VertX for that. Now, I'm not the only one who talks about this evolutionary cycle or how mature you must be in order to take advantage of these capabilities. This is Mark Ballard's version of it. And you must be this tall, right? I love that concept that you must be this tall to ride this ride. If you've ever been on a roller coaster or to a park with roller coasters, there's often a little sign that you've got to be this tall to ride this ride and I'm not particularly tall. So as a little kid, I was the one who did not get on the ride in a few cases. So a maturity model to be ready for microservices. These are the key principles and characteristics. And again, we'll drill down more on these in future sessions. But just know that there's a lot going on in the microservices architecture that we're not gonna spend too much time on today. We're just gonna show you how to build some systems, write it quickly, write some applications quickly. Key concerns. One reason to think of these key concerns or key capabilities is that we tend to run them on Kubernetes because with Kubernetes, we've got load balancing, scaling, elasticity, we get source discovery, you get logging, monitoring, you get a lot of those things for free. And that's why we focus on it from that perspective. And I'll show you a quick example of that, a quick demo of that when we get going. Okay. There's a lot of recorded demos along these lines. And again, we're not gonna spend time on that today, but just keep that in mind that you are also available to you in the slide deck. Now, let's talk quickly about VertX and I will show you some quick demos. VertX is specifically a reactive toolkit. Okay. It's a jar file. You load in your POM XML and you have reactive capabilities you can add it to your application today. It has all these capabilities in the core. So HTTP one and two by default, you can listen for HTTP one or two, UDP, TCP. It also has this concept of the event bus. We're gonna really focus on the core pieces today, but we'll also touch on the router as well just briefly in the demonstration. But you can see it does a ton of other things also. So it can be a full stack CRUD application if you wanted to be get, put, post and delete traditional CRUD, but it doesn't require you to think that way in this new world. So hopefully it'll make sense when we see the demonstration. You're gonna hear this concept of the vertical. Think of it as the programming unit as my class file if you're in Java, but if you're in Ruby, it's just a Ruby program or a Ruby program depending on what language you're using because VertX by default is polyglot. But just keep that in mind. We're gonna be focusing on this concept of the vertical. There's also the event bus that'll be super critical. The event bus of course is distributed across JVMs by default, which allows you to have this nice in-memory programming model that allows you to communicate across all the different components. We'll see that in the demonstration also. The event loop, which is the core architecture of VertX allows you to simply receive events, find dispatchers or find handlers and dispatch to them. So think of that as a central cue where the events are coming in, whether it be responses from other things you've done or just events coming from your user like get, put, post or delete. That's a good example. And if you have multiple cores, which I do on my demo server, you actually have an event loop per core because in a Java LAN, you actually have that opportunity to be multi-threaded. But by default, from a programming standpoint, you don't have to think about that. We take care of that for you by using the event loop, okay? Let's go ahead and show you some quick examples. Let's go ahead and get into the super fast getting started here. And what I'm gonna do is I'm gonna actually just copy and paste directly from these slides, just like you can go into my, let's see here. I have this directory out here called stuff. And I'm just gonna basically copy and paste, okay? So I'm going to paste that line in, which basically says what do you want for a group ID? And I'm gonna say that, and I want artifact ID, 1.0 snapshot, that looks good to me, okay? I can do a Maven clean compile, like a type today package. And there we go. All right, looks like it's good. So basically it generated a Maven project for me. And then you can kind of see it right here. And I can do something super cool like this. Maven products run. So it actually does dynamic or hot deployment. So let's do switch out of here. And let's see, do I have Maven running? Oh, get this set up correctly. Maven, all right, fantastic. We do have a Maven, very, very good. Okay, watch what happens here. We're gonna go to source, main, Java, stuff. There it is. All right, let's just interact with this. So by default, you get this basic vertical, right? You can notice that it's a start method, but we're gonna add some stuff to it. We're gonna make this a little bit more interesting. Well, let me spell things correctly. B-X-T-E-E-W-Eb and router. And let's come over here now and let's add a little logic to it. So the start method is always called by default. This is how you get things going. And I'm gonna say router. I'm gonna declare the router. And so the router is a specialized piece of middleware as part of Vertex. And what that allows them to do is specify URLs in a clever way. So I just hit save there and you can see it's automatically redeploying it. Now we're not done anything yet. I just hit save to see what it looks like and see that it compiles. Okay, let's add router.get. And we're gonna listen for the root of that. So basically any traffic that comes to the root will run this handler. So request and we'll put our lambda in. And based on the index, right, request, we're gonna actually display the host name. So let's do this. And system.getenv.get or default, okay. And we want the host name of the machine we're on. You'll see why that's important a little bit later. Unknown, okay. And then we're going to respond to the request. So request, response, end. And so, hello. So I'm really just coding this up in VI for real here. Not that I'm a VI expert and then those of you who are actually out there going, hey, I love Emacs, I apologize. I don't do Emacs. That's okay though. Host name, okay. And if I did all that correctly, let's close this up now. Bum, bum, bum, okay. And let's write it out. And we'll go and see if we, so it's gonna dynamically reload. Okay, fantastic, it reloaded our thing there. But it's still not actually listening yet, okay. So let's actually show you what it means to listen. So we're going to basically vertex, or X create HTTP server. And we're going to bin request handler. And then we're gonna basically put the router in here. All right, so this is a method reference. So basically it's gonna map the router and then listen on 8080. Now if we did our job right here and I didn't get anything syntactically incorrect, it'll reload and we'll get a nice clean redeploy there. And if I go back to my user interface here, okay. So there we are. So I'm at the browser and that's hello world. And you can see it happening right there and that is this host name. And actually let's go modify this a little bit. Let's take out hello. And I'll come back with my favorite. I'm in Seattle today, but we'll go ahead and put a lo-hi and I'm pretty close to home here. So let's put a lo-hi in, refresh and there's a lo-hi. Okay, so that's our application. Something as simple as that. Now, here's what's kind of cool. I can actually take this down now and I'm gonna go back to the slide deck and I'm gonna copy another command out of the slide deck because one of the things that you can do is now that you filter application, is you can basically map it with fabric eight to make them plug in over to a Kubernetes instance. So I'm basically gonna instrument my pomex, and that's all that does. And then if I come over here and say, cube CTO, get namespaces. All right, let's see OC new project stuff. So this is actually adding a Kubernetes namespace and I can say, made in fabric eight deploy. Okay, so that basically will bundle up everything I need, including creating the Docker image, creating all the YAML files you need to actually deploy to a Kubernetes instance and actually deploy it out there. If I go back to my browser, you can kind of see their stuff and the deployment is happening. Okay, so you can kind of see right there, the deployment is happening. And as it goes through that Docker build, it'll actually create the image and push it out there. And so there's the process it's going through right now. We don't have to stop and wait on it, but just keep that in mind that this is the process you could go through to quickly deploy a new endpoint into a new microservice directly into a Kubernetes cluster. And again, we're gonna see more on Kubernetes in our future session. But I wanna show you a couple other demonstrations here. Okay, let's actually jump over here. Yeah, let's get out of here and go back here. And what else do I have on the server? I got a lot of cool stuff. So we did that one, we did that one. Let's show you the event bus. I wanna show you the event bus just so you get, and just so you see the code. The event bus has this concept of the web server and the bridge. So you can actually use your bridge from the web server out to the browser. So what this allows us to do is bright directional communication from the browser to the server. It also connects all the JVM instances on the server together. So if you actually look at the publisher for Ruby or consumer for Ruby, you can kind of see it's publish or it actually creates a handler right here, consumer. If I publish with Java, same kind of concept here. And I can consume with Java, right? It's a very simple syntax. And we're not really focused on syntax day. I just wanna show you the key capability. So let's go over here and let's bring up the web server. And I'm gonna go back to my browser and let's see. Okay, it's coming up now. Oh, there we go. There we go. So your web server once gets connected, it's gonna basically start shooting messages at the browser. So if you actually bring that up on your phone or you bring it up on your desktop, you'll see the messages along with me and you should be able to see that it was coming to bird out web dot bird out red. I'll notice also I switched from 8080 to just plain 80 to make it a little bit easier if you're typing on your phone. But let's do this now. Let's see. We can actually add another consumer or let's add a Ruby consumer. And so what I'm doing is I'm connecting up things on the server side. I'm gonna add a Ruby consumer and I can also now do a, let's do a Java publisher, okay? So these guys are now coming online on the server side. Gonna connect and right. So connect, connect, okay. And I can see some people join me. That's what the socket connections mean. So I know some people join me. So there's my Ruby consumer and there's my Ruby consumer. And now my Java system is connected. So the Java actually sends out a message that turns the background color yellow. I just thought that would be funny. So you can see Java messages and a web server message showing up there. And if I wanted to, I could just go ahead and kill this and let's do this. Let's actually start pushing out Ruby messages into the mix. So again, all this code is super simple but allows you to do server side push in such a super simple way, super easy. So again, if you're running this on your phone or your desktop, you'll be seeing those messages fly along there. And again, my whole point with this is to show you that what's possible with this kind of technology. And again, it doesn't take much code. If I flip back over to the code, kind of see like my Ruby publisher, where's my Ruby publisher? Simple example, Ruby Now, the date timestamp, and of course the specific feed. That's the channel through all that we've exposed. If you look at my web server here, it actually says that specific channel is what's outbound. So just keep that in mind. You have to have this outbound committed in order for to make that work. Now let's go back over here and you can see now Ruby messages show up as red. So a lot of activity I know happening there but that is just a nice little example of what it takes to actually do something interesting. So let me shut off my Ruby messages. I can shut off my Ruby consumer, shut off my Java messages. So now we're just bringing these things down. You can see I have several things running still and let's go ahead and bring down that web server. Just since I killed Java and Ruby, we're just at a regular web server now. Okay, yep, yep. Let's see here. I wanna see if I have Java processes running out here. Let's see, I do have some still running out there. And let's just go ahead and get your shut down quickly. And boom, boom, boom. All right, still one more. I just wanna make sure we clean up nicely. Okay, maybe everything's down now. All right, it looks like everything's down. Fantastic. So let's show you this. That's a cool example, but I got even cooler one for you. So let's do sudo. By the way, I can do effect jar deployment as well. So you can see that's what we're doing right here. sudo dash jar. The reason I'm using sudo is because it's also running a port 8080. But if you actually connect now to this guy, you're gonna get a little user interface looks like this one. Okay. And then let me bring up my dashboard and let me bring up my phone. My phone, my phone, my phone. Let's see here. All right. Okay. Let's get on the right URL. Ta-ta-ta-ta-ta. Web.bird.red again on port 80. And now what's what happened? So I paint a picture and it shows up here in my dashboard. So if you just go to web.bird.red now, this is an example where we use the event bus in a bi-directional way. Basically, we're connecting from the client side, mobile browser, painting pictures. And then I can basically now, as each stroke finishes on my phone. So if you watch here, I can use it different. As I finish a stroke, it'll show up directly on the dashboard here. So this concept is actually very powerful if you think about it, because now I can build a full reactive application. In this case, it has very little code behind it. And actually the server side of this code is almost nothing. It allows me to basically take an HTML5 canvas from the client side and move it out to the server side and then back out to the dashboard. So I made a little base here. There we go. And it's in yellow. So I guess that doesn't show up very well, but I give them some red hair. That's pretty nice. And you can see other folks are playing along with me and getting connected also. So this concept of the event bus is super powerful and super critical. The idea that you can have this real-time reactive application interacting with maybe a mobile client like see her on my phone or even a desktop client is super easy. And actually, let me flash over to the, you guys can feel free to draw your pictures, but let me flash over here to the code real quick so you can get a chance to see what I'm talking about. The server side of this is super simple. And all this code, by the way, is all open source. In this case, we are outbound and inbound permitted because the same feed, the same bus, if you will, is exposed from taking canvases from the client side and pushing them out to the dashboard that you see there. And you can see it's just listing on port 80. So the server side is just this. That's all it is. The real meat of this effort is actually in the actual client itself with my really ugly JavaScript right here. So really hideous stuff, including the buttons and how you select colors and how you draw pictures. And then really the magic is on this in stroke, right? Send the canvas and basically send canvas, grabs the serialized canvas, makes a JSON string out of it and publishes it on the event bus. So everything you saw earlier, in this case, just client side JavaScript back to the browser standpoint. So you can see it kind of goes pretty crazy, pretty fast. Okay, well, let's see, let's find the right window again. Here we go. Nope, we got a lot of pictures drawing out there. Some people already cleared those. Fantastic stuff and you guys are keeping it clean. I like that, I appreciate that. In some audiences, you get some really bizarre looking images. I just don't, no, we don't wanna call attention to that. Let me show you one more demo that why you guys are on your phone. Okay, and you guys are gonna hang out here with me. Let's see here if we can get this party started. Okay, excellent. So I'm gonna show you one more demo. This is on a different one. This is game.bird.red. Okay, let me bring that up here on my phone. There we go, get connected. So game.bird.red. And what it is, it allows me to pop balloons like fruit ninja style. You kind of see as I pop balloons, I get different accolades there. And so you guys can go to game.bird.red, okay? And then pop balloons, so game.bird.red. But I'm gonna actually bring up some dashboards real quick. Let's make this a little bit bigger. Game.bird.red, all right? So here's a scoreboard. Okay, we've got six people already in playing right now. Feel free to join, cause it's actually a fun game. And let's go to the leaderboard, okay? And so again, there's those six people that have connected, seven are now connected. And you can sit nine, so we're getting people connected now. So feel free to connect up. And what's happening is as you connect, of course, you can see our pop count, our player count goes up in real time. Someone lost their web socket connection. Now two more are joined. You can see our leaderboard for our top 10 scoring folks here. You can see this one's called puppy puzzle puppy over here, so let's score over here. And then of course my mobile app over here. Now, this is a super fun one because of course it's a nice interactive game, but you should understand something about the architecture here. So I need your attention for a second, so let's pause you. Okay, now here's the idea. Let me show you this in the slide deck. Now let's go back over here. Here's why this game's important. We have the Bloom popping game on the client side. It's interacting with a Vertex server via a web socket. This is a single JVM running all you guys pops. We can run hundreds and hundreds of users and currently pounding away on the system. Each pop of the balloon is actually a transaction through a back end microservice for calculating achievements or basically looking at what the achievement options are. And then it actually goes to a traditional JVM application for an intraditional JBOS enterprise application platform and running the Drool's project or the BRMS technology to calculate what an achievement means. Like if you get three in a row, 10 in a row, hit a certain level, right? Those achievements are super critical. So this architecture is all part of the back end. So I recognize I paused you guys. You're probably unhappy with me. Let's go and get started again. Okay, I'll let you guys keep playing. Watch what happens though. I can actually make real time changes to the application. Like make those balloons much easier to hit. Make the red balloons count as 10. Maybe change the background color and then send you an update. So now you have big fat balloons and it's much easier to score points. Where are my dashboards go? Let's see if you guys are really pounding away at it now. All right, fantastic. Okay, so it does look like people are really scoring points like crazy now. You can see the leaderboards changing rapidly. But each pop you guys make is going through that entire back end architecture. And as our achievements are scored, you can see them showing up here in our dashboard here in real time. So you can actually knock those off. And actually there's one more trick in this application I'll show you here. And that's because the team thought it would be funny to add the golden snitch. And so you'll see that show up in the screen. Oh, looks like some people already hit it. There it is. They decided to put my face on a balloon. So as soon as you hit that and get that achievement you score a lot of points and then you can really hit it fast. But look how many transactions already 2000 plus transactions into the system just with 15 people playing with this simultaneously right now. So just keep in mind you can build a really interesting application really fast by simply building a nice product system. And I know I'm running out of time. So game over. Okay. Well, I know I apologize. You guys like, I wanna play some more. Maybe in a future date we'll play some more at some point but you can see there's my puzzle puppy. And then you can kind of see what my screen looks like here on my mobile screen too. Okay. Let's kind of jump back in the slide deck because I promise to you guys we'll hang this, we'll run this about 30 minutes. The repos are all here. And so if you want those balloon repos there's also the demos are here. Keep in mind that the entire slide deck is available to you at goingreactivejava. And then of course monitor debonation live because in the future we're gonna bring it all kinds of cool stuff related to this and more with Kubernetes or Istio and Envoy, deep diving into Docker and Kubernetes as an example on how to build job, bring your Java workloads to it. Of course, big data and other topics. So if it's a cool happening topic and you're interested in it, please let me know. Feel free to hit me on Twitter or via email and we'll continue to bring you great content the first and third Thursday of the month. And again, thank you so much for coming out today.