Bona nit a ToL, bona nit. I, com que sí, ara posem en compte que es veuen els arquitectors de l'Eventiva i tot serà basat en tecnologies novençores. Com que podem veure, ens veiem a Red Hat, però no totes les tecnologies que anirem a fer ens venen a Red Hat. En una raó, tothom és molt preocupat que això serà una sèrie de espèrdues o una altra cosa. No és una raó. En un moment, per primer de tot, et diuen una qüestió shorta. As you can see here, I'm Carlos Arnal, I'm a software engineer, as I said, working for Red Hat. I am part of the Apicorio team. Here it says I work on Apicorio Registry. That is partially true. I work on Apicorio Registry. But the Apicorio community is a bigger umbrella with more projects than just Apicorio Registry. But in today's talk Apicorio Registry is the project that is related to the data pipeline. As you can see, I'm also an active Quarkus comiter, for those who are familiar with the Quarkus project. You are probably more familiar with the Spring project. Quarkus is an alternative coming from Red Hat to the Spring project, a very interesting one. I'm also an associate professor at the Polytechnic University of Catalonia, known as Barcelona Tech for those who like fancy names. First of all, let me make a small warning. This talk is going to be a bit different in the sense that I don't like presentations with a lot of text or anything like that. We will have 12 slides and I will do a live demo. That demo will take most of the time of the presentation. I'm making that warning because I know that most talks take questions at the end of the presentation. Since this is going to be a live demo, I would like that if you have any question in the middle of the demo, please raise your hand, ask the question, and we will continue from there. I will do my best to answer the question, okay? I think that's better because once we are in the middle of something in the demo, once we move to the next thing, it's going to be hard to explain what happened and what not, okay? So continuing with the presentation, this is our agenda for the talk. First, I'm going to introduce you the different components and why we choose them, their benefits, their pros, their cons, and why they are a good fit basically for an event driven architecture. That's the discussion for this talk, okay? As I said, I'm going to do a step-by-step walkthrough of deploying the entire DevTap Island live in the talk. So I hope that the demo gods are with us because it's going to be a live demo. Using different tools like StreamSeq, Kubernetes, and other open source tools, as I mentioned. And finally, I'll do a wrap up and I will share any thoughts we have in the last minute and open the floor for any last minute questions in case there are no questions during the live demo, okay? So, let's start talking about the different components we have. The first component we have is OpenShift. OpenShift is an application development and delivery platform. That allows you to streamline your workflows to get production faster into production. It includes, for instance, building Jenkins pipelines, for example, but it includes a wide range of technologies and a wide range of things, okay? You can also bring together development operations and security teams under a single platform to modernize existing applications. Imagine you have the classical monolithic architecture. You can start bringing your monolithic application to OpenShift and start breaking it into smaller pieces. Or, in case you already have a microservice architecture, that is the new trend, right? We are, in software, we live in the cycle.  The server is a cycle always. And, of course, with OpenShift, you can also go to edge computing. Essentially, you can compute, you can deal with data, you can compute close to the device, close to the source of the data, close, or as close as possible to the source of the data, okay? The next tool we are going to talk about is StreamC. StreamC is, essentially, a Kubernetes operator that allows you to deploy Kafka in an easy way, right? As you see, as, and I'm going to prove it in the live demo, as you see, as with a single Jamel file, you can have your Kafka cluster running in Kubernetes. In this case, it's going to be OpenShift, but OpenShift is built on top of Kubernetes. Everything I'm going to share is works on OpenShift, but it works on Kubernetes as well. So, a typical deployment incorporating Kafka components, and that will be our case today, might include the Kafka cluster of broker nodes. It also includes the Sukiper cluster of replicated Sukiper instances, and also the Kafka cluster for extended data data connections. That will be our case today. We're going to deploy a Kafka cluster, okay? Then, another component, the one I'm more proud of, basically, because I work with a team, right? It's a peculiar registry. A peculiar registry, essentially, it can work basically as two things. In our case today, the use case that is interesting to us is the schema registry use case. What is a schema registry? A schema registry, basically, imagine you have an application that is sending messages to Kafka. Usually, those messages are serialized using a schema, and are serializing using a format, and there it is, Abro, protocol buffers, JSON schema, whatever schema type you are using. So, instead of sending the whole schema with your message, you just identify it and externalize that information to the schema registry application. Okay? So, you have these benefits that you can see here. You can decouple the schema from your application, no more having the schema defined inside the application. You have a central location and a single source of truth for all your schema definitions. You can have different schema registry deployments, one for production, one for preproduction, etc. Or just one, and having different access management controls. And, of course, one of the very interesting things about the schema registry is that they are a centralized schema evolution place. You can define all the rules to ensure that your schemas can evolve in a safe manner, in the sense that you can define forward and backward compatibility rules for your schemas, and you try to define a new version of your schema that breaks those compatibility rules, then your producer won't be able to publish new messages, in this case, to Kafka, but to any messaging platform, preventing those messages from being corrupt for the consumers. Okay? Then, another very interesting tool for those who are not familiar with it is Divisium. Divisium, essentially, is a change data capture platform. And what's that? In our case, we are going to be taking information from a progress database, publishing the changes in the progress database to Kafka, and getting those changes into elastic search. How does Divisium does that? Divisium lets your apps react every time your data changes, in the sense that you don't have to change your application to modify the data. It continuously monitors the database changes, basically translating logs, as you can probably imagine, and stream every row level change from your application, you can see all the changes and deal with them as you see fit. Right? So you can, as you can imagine right now, you can take that functionality from your application and put it into a different service. No more, as you can see in the second point, no more need for a single application to deal with everything. I am going to update the database. I am going to update the search indexes. I am going to push the cache. I am going to send the notifications. No more need for everything in the same application, right? You can have that code and that functionality separated into a different place. And, as I was saying, it's looking at the transaction log, a very important part, because without that point, none of the others makes any sense.  It doesn't matter the amount of your applications, so you are not going to miss any bit of your changes. Okay? Now we have finally the last tool, so to speak, that we are going to have in this presentation, that is Elasticsearch.  We are going to use it for build searching indexes for applications. And some of the characteristics is that it's very easily configurable. I can prove it in the live demo. It has very good scalability capabilities. And you can ingest data from any place, right? You can ingest data from a database. You can ingest data from any other place, right? You can ingest data from a lot of places. And now, getting into the interesting part. As I was saying at the beginning, we are going to use a PostgreSQL database in this presentation. That PostgreSQL database is going to be populated already with a few tables, in the sense that we are going to have, if I recall correctly, because it's been sometimes I look at the database. I was kidding. It's five tables. One with customers, one with product items, a classical database. We are going to deploy a PostgreSQL source connector that is going to take the changes in that database. It's going to publish those changes serialized into Kafka. How it's going to do that serialization? It's going to serialize that information using this serialization technology provided, in this case, it's a schema registry. It's a peculiar registry, the project I work for. So it's going to use that technology to serialize the changes in the PostgreSQL database. Send that information serialized into Kafka using Gapro. And then we are going to take those changes with the elastic search scene connector. And we are going to build a search index with those changes. You can see another element in the middle. That is the Kafka UI. The Kafka UI is a very interesting tool. It's another open source tool that allows you to browse your Kafka topics, your Kafka messages, everything that is related to Kafka. And we are going to see it in the presentation. Okay? And now, if you scan this QR code, it's a bit different, but if you scan it, it will take you to the GitHub repository that is the base for this presentation. So I'm going to do it. If you're curious after the presentation, you can go to the GitHub repository and you can do exactly the same as I'm going to do in the presentation. Okay? Exactly the same. So I can prove that it works and you can deploy the exact same thing I'm going to deploy. So let me actually exit the presentation. Okay? Let me change this thing in here. Just a moment. So we can see the same because in the other screen it's a bit too small for me. So a second because I want you to have the other part in here. Okay? I hope it's readable. It's fine. I can make it bigger. It's fine. Okay? Great. So let's start. This presentation basically starts with the very first component. Why? Because it's the component that every single component you can see the information in here. In case you don't know what I'm talking about. So the very first component we are going to deploy is StreamC, the StreamC operator. And the StreamC is the streamC operator. Now I can see that there are changes from the port address database to Kafka. So if I don't have a Kafka cluster to send those changes, I can't do anything. Okay? So for this presentation I already have an openJiv cluster deployed and available. It's basically very similar to a Kubernetes cluster, in that sense. La primera cosa que faré per aquests quarts familiars amb OpenShift és que hi hagi una mena aquí i hi haurà la cap d'operator. És un lloc on hi haurà operators i hi haurà l'operator de streams, que és l'operator de Kafka. I ara, què passa aquí? Això és creant un nou deployment en Kubernetes, en l'OpenShift Cluster. És una mica més o menys de temps per instal·lar streams. És la més clara cosa en la presentació. Perdona, perdona. Però, com veieu, l'operator ha estat creat. Ara estem esperant per l'operator per ser prou. I, quan és prou, continuaré amb la presentació. Bàsicament, això ens permetirà crear unes setmanes de definicions customes per la Kafka Cluster, per la Kafka Connectors, per la Kafka Connect Cluster, etc. Aleshores, veuré tot l'informació per la Kafka Cluster. Si és prou, si no funciona, i així, veuré tot. He promès que hi haurà 2 minuts. Si veuré l'operator, com he dit, ara, aquí, hi ha tota aquesta informació. Hi ha una etapa per la Kafka. Això és per la Kafka Cluster. Obviamente, no he creat una Kafka Cluster encara. No he fet res definit. Són per la Kafka Connect. I la mateixa cosa per la Kafka Connectors. Aquestos són els 3 elements que utilitem avui. La primera cosa és la Kafka Cluster. La segona cosa és la Kafka Connector en temps. I l'altra cosa és les Connectors que s'han desplegat a la Kafka Connector. Continuant amb la presentació, la primera cosa que faré és desplegar la Kafka Cluster. He tingut un avançament de definicions customes definits en aquest fil. Després que has aconseguit la repositoria, pots veure què hi ha. Això és un telèfon, i el telèfon que l'ha fet és un telèfon. I ara, a la costa de fer-ho, per exemple, ho faré perquè la ressona el telèfon del telèfon. A la resta de la resta de la ressona, la ressona de la ressona de la ressona del telèfon. I la resta de la ressona de la ressona de la ressona es fa a la ressona de la ressona de la ressona. i l'extremament consisteix en tres coses. Una és la clàssica, que és un coordinador per la clàssica, l'altra és el broker per a Kafka, i després aquest operador es va deployar una altra cosa, que és el operador per a aquesta clàssica en particular. Així que, com veieu, tenim tres potes de clàssica. Tothom és usually deployed in a-cluster manner, i aquí hi ha tres potes per a la clàssica de Kafka. Quan això és prou, creu una altra pota que serà l'operador d'aquesta. I, quan això és prou, la clàssica de Kafka serà prou. Ara, el que volem demostrar és que, si aniré a la instal·lació de la clàssica, veieu que ara hi ha una clàssica de Kafka creada a l'extremament. He creat la clàssica de Kafka manualment, utilitzant l'oci-appli comandant en el terminal, però la clàssica de Kafka és stillada per a l'extremament. I, com veieu, ara la condició de la clàssica de Kafka ha canviat. Ara tenim una clàssica de Kafka deployada. Continuem amb la presentació. I la següent cosa que deployaré és l'interface d'un user per a la càssica de Kafka. Què és l'interface d'un user? És el que vaig mencionar amb l'interface d'un user. I l'execucaré el comandament i pararé en el meantime. Això és l'UI per a la càssica de Kafka. A l'aigua m'ha d'obrir les meves tòpiques, les meves missatges, les esquemes, tot. Ok, doncs ara, si anem a la clàssica de la meva clàssica i anem a les deployments, vaig crear una deployment per a la càssica de l'UI. Vull veure que hi ha una deployment, hi ha un bot per a la càssica de l'UI, l'interface que funciona. Ara, si anem aquí, les routes... Un moment, per a l'interface, però veuràs que ara hi ha una molt bona UI per a la càssica de Kafka. En quin sentit? En el sentit que... Òbviament, no hi haurà cap tòpic aquí, a part de les tòpiques internals, perquè no he fet res. Però veus que aquesta interface d'un user és already connectada amb la clàssica de la meva càssica de Kafka. Ara, anem a deployar la segona cosa que és... Em porto el meu espai. I això anirà a deployar l'Apiguria Registri Operator. En el mateix sentit, és un operator de Kubernetes que et permeti managesar l'Apiguria Registri. Són amb la càssica de l'Estream for Kafka, això és el mateix, però per l'Apiguria Registri. Ok? A veure, anem i deployar l'Apiguria Registri Operator. Same thing. Fine, I have the Operator installed, but I don't have any Apiguria Registri instance available to me. Ok? So, now, same thing, as I have done with StreamSea. I have the only difference is that for StreamSea I have installed the StreamSea operator from the Opensiv console and for Apiguria Registri I have installed the Operator manually. We also have the Operator available in Operator Hub for Apiguria Registri. It's just more convenient for me to do it that way. Ok? So, as you can see here, this is going to create an instance of Apiguria Registri. And you can see two things. The very first thing is that the new Apiguria Registri instance has been created and the second one is mentioning that a Kafka topic, Kafka StreamSea has been created. What does that mean? That means that Apiguria Registri can work into different manners. Ok? The first one is a more traditional, if you will, in the sense that for storing all the information it's going to use a relational database. It can be Postgres, it can be SQL Server, it can be MySQL, and you get the idea. Ok? Or the alternative for those who have a Kafka cluster already available, like us in this case, you can use a Kafka topic for storing all the information, for storing all your information, all your schemas, all your rules, everything that Apiguria Registri manages. Ok? And now, if I go here, you can see that I have a new, another route for my Apiguria Registri instance. The first time it takes a bit of time. The cluster is a development cluster, so it's not really, really fast. So you can see here that they have now my Apiguria Registri instance without information, but it's available. For now we are only deploying the different components. We are going to use the demo later. Ok? So, the very next thing, for those who don't remember the beginning of the presentation, one of the last things we need is Elasticsearch. So, for deploying Elasticsearch, the very first thing I need are the CRDs for Elasticsearch. Ok? So I can create an Elasticsearch instance, I can deal with all of that. So, let's go ahead. And you are seeing Unchange. I wanted to do it for the presentation. You are seeing Unchange in this case, because I already have the CRDs for Elasticsearch installed in this cluster. Ok? But you would have seen created in this case instead of Unchange. And the second step, as with StreamC, as with Apiguria Registri, is to install the Elasticsearch operator. And in this case you can see that all the resources required for Elasticsearch, the Elasticsearch operator are being created. Now, as I was saying, the very same thing. Ok? I need to create my Elasticsearch cluster, so I am going to go ahead and create Elasticsearch instance. As you can see here, Elasticsearch has been created and also a route for it to be available has been created. Ok, now, if I go to routes, if I go to Elasticsearch, if it's already available, if not, I will go to the bot itself to see what's still not available. So, you can see here that it's being idealized. Now, if I refresh this thing, ok, now it's available. The classical message hello world in this case for Elasticsearch is, you know, for search. It's quite obvious, this way you know that the Elasticsearch instance is working. Ok? So now, what else are we missing for this presentation? I said at the beginning that the very base for the presentation was going to be the PostgreSQL database. Without it, there is no presentation, without the PostgreSQL database. Ok? So, the next step is going to be to install the PostgreSQL database. For convenient reasons, as I said at the beginning, this PostgreSQL database already has a few tables created, five tables in this case, and some data, a few rows for each table. Ok? So, now I have the PostgreSQL database. Fine, it's there. I don't need to check it now. And the very next thing is going to be when I was talking about the StreamC, I talked about the Kafka cluster, also keeper, and I talked about KafkaConnect. KafkaConnect is a runtime that allows you to deal with external data, in the sense that allows you to deal with, in our case, with PostgreSQL data, and to send data to Elasticsearch. But to be able to deploy my connectors, first of all, I need a KafkaConnect cluster. Ok? So, let's go ahead, and let's create a KafkaConnect cluster. This is going to create, basically, two pods. The first one is going to configure the cluster, and the second one is going to be the actual KafkaConnect cluster. Ok? So, let me filter this thing here. As you can see here, the first one, the build one is running. Once this pod is done, the KafkaConnect cluster will be configured, and another one will appear here, that will be the actual KafkaConnect cluster. As you can see here, this one has been completed, and, as I promised, another one has appeared, that is the actual KafkaConnect cluster. Now, we need to wait for this one to be ready, but, same as I said in the meantime, same as I said with Kafka, with the Kafka cluster itself, if you go here to KafkaConnect, you can see that the KafkaConnect cluster also appears in the StreamC user interface. So, I have created it manually again, but it's still managed by the StreamC operator. Ok? Now, this status is not ready yet. Let me check the connect pod. Usually, it's just that I'm not patient enough to wait for it to be ready, but sometimes it works checking the logs, as you can probably imagine. For now, everything is going smoothly. I actually think it might be ready. So, it was that... I'm just not patient enough to wait for it to be ready. Ok? Now, getting into the interesting part of the presentation. Ok? I'm going to deploy the very first thing, the PostgreSQL source connector. Source in what sense? In the sense that this is the connector... Sorry, let me deploy it. So, source in what sense? In the sense that this is the application that is going to take all the information from the PostgreSQL database, it's going to serialize those changes, publish them into Kafka. So, all the changes from the PostgreSQL database will be available in the Kafka cluster. Ok? Now, if I did everything correctly, if I go to install operators, and the Kafka connectors are at the end. Ok? You can see that now I have a PostgreSQL connector with the condition ready. And now, getting into interesting things. What happened here? Please. Collecting to the changes in PostgreSQL is it only insert update or also table changes? Take the changes. We will see it in the presentation. Taking the changes. Ok? So, as you can see in here, now, for each table in the database, as I promised, there were five tables. Ok? For each table in the database, a new topic in the Kafka cluster has been created. So, for instance, I already had some data in the database. If I go here, if I go to the messages, here we have two interesting things. The first one is that in here, you can see that the Kafka UI is not able to des-realize the key for this Kafka message. What is going on?  And as I said, that is not true. All of this is Avro binary data. So, that is not only that this Avro binary data, but that schema is not present in the message itself. It's present in the schema registry. So, if I change this, if I change the key server, you can see already that the value server is set to schema registry. If I do this, you can see that the key can be des-realized on the fly in the Kafka UI. And if I go to my Apigurio registry UI, and I refresh it, you can see that for the values, for the keys and the values for those messages, a new schema in the schema registry has been created. In the sense that I have this, this is the customer that they was showing. And if I go to the content, you will see that this, basically this corresponds, this is an Avro schema that has been inferred from the information in the database. And this is the schema that is now present in my schema registry. So, this is the schema that is going to be used to serialize and des-realize all the Kafka messages that are going to be on this topic. This allows what I was saying at the beginning. This allows to enable schema evolution in the sense that if I add a new column to the database that is in some fashion incompatible with evolutions, that message might end up being in the Kafka cluster because the producer won't be able to serialize that data. Okay, that is an interesting part. And now, let's continue with other interesting things. The next interesting thing is, we have to separate parts, okay? The first one is information from the Postgre database going to Kafka, and the second one is information from Kafka going into Elasticsearch. For doing that, I need to create the Elasticsearch sync connectors. Connectors, because I have five topics, one for each table, five sync connectors, okay? So, if I do it, you can see that one, two, three, four, five. And in the StreamCUI, you can see that my sync connectors are already present in there, okay? Now, the very interesting thing, here it says what I'm already saying that you can see it in the StreamC. And now, the other interesting part is that this is an extension that is mentioned in the guide. So, don't worry, you don't get something of what's going on. This extension that I'm going to use is mentioned in the GitHub repository and in the guide, okay? So, if I go to this extension, here I already have my Elasticsearch cluster connected. If I go here to indexes, what happened here? I already have five Elasticsearch indexes created, one per each topic, one per each table in my PostgreSQL database. So, if I go to customers, I'm showing customers because they are just convenient for this case. You can see that I have four. Customers, that is information that they have available in the database. If I go to the Kafka UI, you can see the very same thing. You can see that there are four Kafka messages, there are four customers, okay? It's the very same thing. So, I have the information in PostgreSQL that information is flowing to Kafka and finally getting into Elasticsearch. So, all the data pipeline is finally connected, okay? But now, let's do something more interesting. This is fine. I took the data from the database, the data is in Kafka and the data is in Elasticsearch, but let's use this, right? And let's see how fast this is to actually send information from one place to another, okay? So, what I'm gonna do first is to connect to my PostgreSQL database. Okay. And now, let's... And as we seen in the Kafka topic in the Elasticsearch, if I do this, I have four customers, okay? Fine, great. What happens if I do this? Basically, inserting a new one, okay? What is gonna happen in here? It's already in my Kafka cluster, it's already present in there, in there, and what is gonna happen in here? It's already in Elasticsearch, as well. A new row has been inserted into the database and in a matter of milliseconds I'm actually slower typing to move from one place to another than the data flowing from one site to another, okay? So, in a matter of milliseconds, the data has moved from the database to Elasticsearch. But let's make it a bit more interesting in the sense that let's update this customer email to something actually different. And you can see that the email has already changed en Elasticsearch. I'm not even going to KafkaUI, I'm not even going to Postgres, it's already changed in Elasticsearch to see and to prove how fast this kind of setup how fast this kind of deployment is. And finally, kind of the kind of the same, but very similar in the sense that I want to show something a bit different in the KafkaUI, okay? I'm gonna delete this customer in particular. Fine, if I update Elasticsearch, disappeared, no more. And if I go to the KafkaUI, something interesting is gonna happen. Instead of just one, now I have two Kafka messages for this customer in particular. What's happening here? So, the first one is pretty obvious. I have some information for this, related to this message and this was the information I had. The third name, John, Doe and this is the email. And then, the data after, obviously, because I have deleted this customer in particular, there is no more, this customer is no more in here. The second message, and that is the interesting part, is a Thompson message, in the sense that when Kafka runs no compaction, it's gonna detect that all the messages associated with this identifier can be removed. Because they are no longer relevant for dealing with this data. There is no more John Doe in the database. So, it doesn't make any sense to have John Doe in the Elasticsearch index. So, why having the messages in Kafka? Whenever compaction runs, just get rid of those messages. We are using storage for no reason. Okay? And this is basically all I wanted to show in the live demo. The conclusion, as you can see in here, is that is what I was saying, is that I'm actually slower typing and moving from one user interface to another than the data actually flowing from one component to another. The human in this case is slower than the actual components. That is the very interesting part. And, as I was saying, you never miss a bit. You have here messages in Kafka for updating everything. And that is it. I mean, this is the live demo. As I said, in the GitHub repository you have exactly the same set of commands I have executed. The only thing you need is either an OpenGIF cluster or a Kubernetes cluster, and you can do just don in the presentation. And now, let me go back to the presentation just because I want to show the classical one last thing in the sense that in this presentation I have talked about a few projects. The first one was StreamC. StreamC is already a CNCF sandbox project. I haven't mentioned one of the cool integrations of these two projects, that is Keyglock. Keyglock is already a CNCF incubating project. And I mentioned it here because it has a nice integration with both Epicurio Registry and StreamC. And for Epicurio Registry we are a younger project than StreamC and Keyglock. We are already present in the CNCF landscape. And last week, if I remember correctly, I submitted the sandbox proposal for CNCF. And that's all. Thank you very much for attending the presentation. And we have a few minutes left. If there is any question, I believe. I didn't understand exactly where was Deepism involved in the demo here. It's in the KafkaConnect cluster. It adds capabilities to KafkaConnect. Epicurio is usable with other streaming storage than Kafka i has a bunch. No, no. We are working on a new version of Epicurio Registry. We are aiming at having support for other streaming platforms. I'm actually working on the issue for having support for Apache Pulsar. We are not there yet, but we are trying to get there. Thank you. If you don't have any questions right now, don't feel free to drop an email or anything. Everything is open source. You can even go to the GitHub repository and open any issue if you want.


All right, thanks everyone for coming to building microservices with .NET Core and Steeltoe. Hopefully, you're in the right place. Quick introduction. I'm Matt Horan, a software engineer at Pivotal. I'm Zach Brown. I also work at Pivotal. And what we're going to talk about today, quick introduction to the .NET Renaissance. We'll talk a little bit about what is Steeltoe and why did we build it. We have a quick demo and then a roadmap and resources at the end. Please be engaged. We'd love for you to talk with us after this talk today and reach out to us on Twitter. Follow Zach or the Steeltoe project. And please engage with us. So Zach, why don't you tell us about this so-called .NET Renaissance? I don't mind if I do. All right, for some people in the open source world, when you hear the words .NET, you don't automatically think cool. Maybe you think old school. I suppose they think that all the cool kids are writing Golang and Node apps nowadays. Well, there's a lot of stuff that's been happening up in Redmond. A lot of changes are under foot. And ultimately, they make right now, this very moment, a very exciting time to be a .NET developer. In case you're not clear what I'm talking about, let me refresh your memory. Microsoft loves Linux. You can now run Bash on Windows. You can run Linux containers on Windows. I mean, who could have seen this coming? It was just a few years ago. This would have been unthinkable. I really personally, I hope, somewhere deep down inside of me that someone at Microsoft has printed up one of those Linux heart Microsoft loves Linux t-shirts and sent it to Steve Ballmer, because I'd love to see him rock that. Microsoft loves open source. To me, this is obviously another massive pivot. But to me, this is even bigger, more significant than the Linux thing. A previous incarnation of Microsoft viewed open source as competition. In fact, there were probably times that they deliberately tried to put open source out of business. So the fact that they're moving towards this model of embracing the open source community is something very significant. And as an example of that, .NET itself is now open source. It's managed by the .NET Foundation, which aims to cultivate and foster a community around .NET. It includes the .NET framework, Roslin, Xamarin, Mono, plus all sorts of community projects. And then more recently, it includes .NET Core, which is a new cross-platform set of runtimes and frameworks that runs on Windows. It runs on Linux. It runs on macOS. And of course, Visual Studio had to get in on the LoveFest. There's a full-blown Visual Studio IDE now for macOS. And they've come out with a new lightweight editor called Visual Studio Code. It runs on Mac, Linux, Windows. But wait, that's not all. SQL Server now runs on Linux. Wow, look at that. Look at all those hearts. What are we meant to take away from this? Does anybody remember when you were in school and you wrote your name and maybe somebody else's name on a piece of paper with a heart in between? Or maybe you were really serious and you carved it into a tree trunk or wrote it in wet cement? So what are we supposed to take away from all these hearts? Microsoft must be getting really serious about this stuff. All right, so what's all this about a .NET Renaissance? At the NDC conference in Oslo this summer, Ian Cooper called out the Java rejuvenation renaissance of five or six years ago and drew some parallels and said that we can draw some conclusions from that, that .NET is in the same place. So basically he said, where at one point you were seeing the JVM lose ground to Ruby and Rails as more developers started turning towards that low-friction web development experience and away from the heavy-duty enterprise app servers, suddenly there was this renaissance of projects like NetE and the Spring Framework and even Netflix OSS where there was a rich community of projects around cloud-native and 12-factor and microservices. And right now we're on the verge of such a renaissance in the .NET world. So by comparison, .NET had its 15th birthday this year, whereas Java is closer to 20 years old. So maybe in the terms of the time frame or around the same timing, you know, with the introduction of .NET Core, given Microsoft's pivot towards open source, we're really turning to a point where .NET is on the verge of this massive renaissance. So what's missing? Well, what's been missing, at least until very recently, is that rich community of cloud-native, 12-factor microservices projects. And that's where Steeltoe comes in and that's what we're going to talk to you about today. You want to tell us what Steeltoe is, Matt? Perfect. So Steeltoe is an open-source project sponsored by Pivotal that brings client libraries for Spring Cloud and Netflix OSS to .NET. It also provides tooling that makes it easy to deploy and run .NET applications on Cloud Foundry and leverage Cloud Foundry services. But before we talk about what's in Steeltoe, let's talk about why we built it. So why is Steeltoe? If you're building cloud-native .NET applications, specifically, to run on Cloud Foundry, you're going to be embracing 12-factor principles. So you want to move away from just having random application dependencies in your code base and just checking binary blobs into your code, move to something like Nougat for storing those dependency references, right? Storing configuration in the environment. So instead of hard coding database strings and other settings into your code base and then checking that in and shipping around a password to everyone, you want to move that into something like a configuration server. You don't want to be storing session state in your process. How do you scale horizontally an application that just stores that session state in memory? Then you do things like jSession ID and session pinning, right? That's not a great way to scale out your application. You need to break down tight coupling between your application and the server it's running on. Guess what? For .NET, that means you can't use the Windows registry. You don't want to use the global assembly cache, the GAC. You don't want to write things to the local file system and rely on them being there. They won't be there when you scale up or down your instance, right? And when you're using a data store, like maybe a relational database, you need to loosely couple your application to that. Again, just like configuration, you've got to find a way to inject that into the application and then swap it out based on, well, are you in Dev, Test, or Prod? Are you working locally? Are you working on Cloud Foundry? So I just got a saying, today's best practices are tomorrow's anti-patterns. Of course, that means yesterday's best practices are today's anti-patterns, right? That would follow. So what this means is there may have been things that you did five years ago in .NET that made a lot of sense. And it worked really well. And that was fantastic. But today, as you're embracing something like Cloud Foundry and you're trying to scale out your application and modernize it, maybe some of those decisions are interfering with application resiliency or scalability. And so you need to reset. Second, well, you can't go to a technology conference and not hear about microservices, right? So I promise you we'll talk about microservices. Microservices allow developers to quickly iterate on small components and divide up responsibility. What you get out of this is being able to onboard developers to a project more quickly when you've broken down a gigantic application into component pieces. You can onboard a developer to one part of the system. We'll show you a demo application where it's broken up into four components. And you have somebody working on the front end and somebody working on one of three back end services. You can quickly iterate on your test cycle. So instead of waiting for the entire integration test suite to pass and then wasting a lot of cycles there, you could just run unit tests that are concentrated on the piece of code that you're iterating on. And then you can come together at the end and just run a full suite of happy path tests, right? You can also choose the right language to solve a problem. You can do this polyglot architecture. And so say you have an application that needs to run on the desktop.net CLR, right? It requires Windows for some reason. But then you're trying to save your company money and you also want to use Linux to run some of that application. So why don't you split up your microservice so that that back end that needs access to Windows, well, that runs just fine on the desktop CLR with Windows support in Cloud Foundry. And then everything else runs on Linux. Maybe you write a node app. Maybe you write a .net core app. You can mix and match as you see fit. You can also scale components independently of each other.  You can scale it down. You can scale up your back end all independently of each other, right? So microservices bring some great benefits to the table. They also have some challenges. So microservices, by definition, are a distributed system, right? So there's a ton of complexity underneath there. What if you're trying to find a bug in your application? Well, if it's a monolith, right? The bug is probably in that gigantic code base. So you know where it is. You can go and find it. No problem. But troubleshooting a microservice or set of microservices is kind of like solving a murder mystery. So if you're into that, it's great. It's also really easy to set global configuration and read it from anywhere in a monolith, right? You have one giant code base. You throw it in some, I don't know, what do kids like these days? XML, JSON, something like that, and it's everywhere, right? So in a monolith, that's easy. How do you do that in all of these tiny microservices? How do you get all that configuration out to every single one of those, right? Copying an XML file and checking it into a bunch of code bases is not really a good way to solve that problem. What if those microservices are in a bunch of different languages, written in different languages, right? Maybe one of them doesn't have a JSON parser. I don't know. If a microservice you depend on is running at this horizontal scale and dynamically scaling up and down, how do you find healthy instances and only route traffic to those, right? And if you have all these instances that are scaling up and down, and one of them becomes unhealthy, how do you handle that? What do you do when an instance goes offline? Well, the good news is our friends at Netflix already solved a lot of these problems. However, they solved a lot of these problems specifically for their deployment on AWS. But the Spring team, which Pivotal contributes a number of developers towards, has been working on making generic implementations for a lot of the Spring Cloud open source libraries for the Java programming language. But wait a minute. How does that help .NET developers? Well, that's why we're here. Steeltoe was built to help you build cloud-native .NET applications and leverage Spring Cloud tooling for resilient microservices. Check out all those buzzwords. Cool. All right, so let's talk about what's inside the box. First, a look at the components in Steeltoe that are geared towards building cloud-native .NET microservices, building applications that run on Cloud Foundry. So Steeltoe connectors, they simplify the process of connecting to and using backing data services on Cloud Foundry, things like MySQL, Postgres, Redis, RabbitMQ, OAuth2. They provide out-of-the-box support for discovering many of those services as long as they're bound to your application. And they also include the ability to do settings-based configuration so that developers can supply configuration settings at development time for their on their local system and then have them overridden when you push your application to Cloud Foundry. Steeltoe also includes a number of security-related services so that you can simplify things like using OAuth2-based UAA or Pivotal SSO on your application, accessing JWT-protected resources like the Cloud Controller API. Additionally, Steeltoe makes available an additional security provider. The ASP.NET Core Data Protection Library includes a keyring store. But the way that they've implemented it by default, it writes the keyring to the local disk. Since that's not a very cloud-native pattern, what the Steeltoe project does is it makes available a way for you to override that configuration and write those keyrings to a Cloud Foundry hosted Redis instance. Steeltoe also helps you manage and troubleshoot your microservice by ornamenting it with a set of standard management endpoints. These were inspired by the actuator library in Spring Boot. They're non-invasive, so you can get visibility to the problems where they're actually occurring, even if that's in production. And you can access them on an instance-by-instance basis for your microservice if your microservice is running at horizontal scale. So they include info. So this is an information endpoint. It includes a git hash. So if you're trying to solve that problem of figuring out the running instance of your application, which commit does it actually correspond to in your Git repo, then it makes that a lot easier. There's a health endpoint to see health information about your application. A trace endpoint that returns the last 100 HTTP requests and responses. And then the most powerful is the logger's endpoint. So this allows you to both see and configure in real time the logging levels of your application. As I said, on an instance-by-instance basis, all the way down to the class level in your application. So it's extremely powerful. All right. So Steeltoe also includes configuration providers. There's this .NET configuration API. It enables you to pull configuration data from a variety of sources. It loads it into a hierarchical dictionary of key value pairs that you can then access inside of your application. Out-of-the-box .NET gives you things like command line arguments and file sources like JSON files or even XML or .ini files, heaven forbid, and environment variables. But Steeltoe adds two custom providers to that list. So the first is a Cloud Foundry provider. It parses the standard Cloud Foundry environment variables and then makes them available to you as configuration data from inside your application. And then the config server provider, it enables the Spring Cloud config server to be used as a config data source. So what does that mean? What is Spring Cloud config server? According to the 12-factor principles, you're supposed to separate your configuration from your application code. Definitely, whatever you do, don't check your connection strings or other app secrets into your source control repo. But that begs the question, well, where do you put them then?  So the way it works is you push your configuration, could be stored in YAML files, for example, into a Git repo. It also supports Hashicorp Vault as a back end if you want to store application secrets in there. And then all of the changes to config are versioned. They're auditable. Then when your app comes online, it pulls the latest config values from the server. It's also possible to call an endpoint on your application that tells it to refresh configuration without having to stop and restart your application. So you can refresh config without any application downtime. All right, service discovery. Service discovery is a pattern that allows you to dynamically bind at runtime to microservices that your app depends on. This is valuable when those services are running at horizontal scale, adding and subtracting instances, constantly changing addresses, especially if those services that you're calling, they live behind a firewall and they aren't publicly addressable. So you can't rely on DNS. Steeltoe implements Netflix Eureka for service discovery. And the pattern works like this. Microservice register themselves when they come online, and whether that's because they're just been deployed or they're scaling out and in. And then the Eureka server periodically checks in to make sure they're still alive and keeps its server list up to date with healthy instances. When a consumer comes online and wants to consume one of those microservices, it first pulls the server list from the Eureka server and then gets periodic updates confirming the current state. Then your application can make calls to the microservices it depends on, even when they're ephemeral, dynamically addressed, scaling in and out, et cetera. It's built to be HA so that if the Eureka server goes offline, your application keeps a cashed copy of that list. It's able to continue to use it until Eureka server is self-healed and comes back up. And now, Histrix circuit breakers. So Steeltoe includes a full .NET implementation of Netflix Histrix Circuit Breaker.  Histrix also includes rich metrics, as well as a dashboard, to visualize the status across all of your microservices. So a little bit more about how it works. This is a quick high-level overview. As long as the dependent service that you're calling remains healthy, the circuit breaker remains closed and all calls are passed through. When a failure threshold is reached, however, the circuit breaker opens up and falls back to a default response or data set, a default fallback behavior. And that gives the service time to recover. So it stops sending requests to that service so that it can self-heal and come back online. Every so often, the circuit breaker will switch to a half-open state where it allows your request to go through to check the status of that service. If the call succeeds, then the circuit breaker goes back to closed. OK, so just generally speaking, Steeltoe works both with .NET Core, this new Linux or cross-platform runtime, as well as .NET Framework. Works both on Windows and Linux. It works standalone. And it works running on Cloud Foundry, of course. All right, well, having said that, let's take a look at a demo. Matt, you want to show us? So I'll just walk through a quick set of architecture slides to talk about what the demo is doing, and then we'll show you how this works. So we took the Music Store reference application from the .NET community. This application is known for exercising the entity framework and ASP.NET Core. It's a monolithic application. So everything's just in one giant code base, and it's just a sample app. You can go to it. You put some stuff in a shopping cart, and you can check out. There's a library of available albums, and then that's pretty much the gist. We broke that down into multiple microservices that correspond to different business functions. And so there's a Music UI, which is just the front end. The Music Store, which is that library of albums that are available. The shopping cart service, which can hold the things that you're looking at purchasing, and an order of processing service, where you can actually check out. This is all implemented using the proxy microservice design pattern, and a single application that Music UI calls out to each of these different back end services to perform the related business functions. There's also a Redis cache for application session state to allow that Music UI to scale out to multiple instances. The application config is stored in the Spring Cloud config server. So this allows all those microservices to know what they need to do and how to do it without having that hard coded in the configuration. The configuration provider automatically injects the connection for the Spring Cloud config server into those microservices. Then we utilize Steel Toe connectors. Connectors automatically detect the back end services that each of these instances have been deployed with and configures the connections to them. So instead of having to hard code your MySQL or Redis connection string into your application, the connectors automatically instantiate the libraries and connect your application to those data stores. Service discovery is implemented using Eureka. So when each of the back end stores, the Music Store, the shopping cart, and the order processing service come online, they register themselves with the Eureka server. Then the Music UI service reaches out to the Eureka server and says, hey, where's the Music Store? OK, and then gets back the URI for that. And you can use the standard .NET HTTP library to call out to them. So it's all relatively seamless. Finally, we decorated the microservices with some management endpoints to make them easier to troubleshoot so you could turn up or down that logging. You can get the health check. You could see the Git SHA that was actually deployed and where my home directory is when I deployed the application. So let's pull this up. I need you to log in, Zach. You're going to have to drag it over to the other screen. Cool. All right, that's visible. All right, so this is the sample app. If you had just deployed that reference app, it would look exactly like this. We changed nothing with the UI, except for breaking up the back end services. So here are all the albums that are available for purchase. You can even drill in further to specific type of music. So I can go ahead and add this to the cart. So looking back at the architecture diagram, maybe. Maybe not. There's the front end, which we were just looking at, reaching out to this Music Store back end. You can swipe back to it. There you go. So then when I add this to my cart, that front end service inserted a reference into the shopping cart, now that actually got stored in this MySQL database. And if I were to go to checkout, I'm actually asked to log in. So this is in the Music Store UI. I will enter my secure password. And I'm brought to this checkout page. Now, I'm not going to bore you with filling this out. We all know how forms work. But if I were to fill this out and submit it, that would go to the back end order processing. We mentioned this Redis Store here and why that's meant to help you be able to scale out that front end application. As you can see here, I'm logged in as me. If I keep reloading the page, I'm still logged in as me. And when I go over to the application dashboard here, I see that my Music UI actually has two instances. And so because we have that Redis Backing Store for the session state, I can scale this up to 10, 1, 5, whatever. So Redis is being used as that backing store. If I go back to my applications here and look at the Music Store app, you see this icon up here is actually notifying us that this application has been extended with that Info, Health, and Logger API. So there's some additional functionality unlocked in the application manager console here. I can click on this instance and get a health check of the disk space that's available in my container and the status of my service that I'm attached to. I can also get the trace of the last 100 requests that were made to the application, including all the headers that were in the response and request. And under Settings here, I can see the SHA and the directory that this was pushed from. So if I'm trying to trace a bug down, that makes it easy. Finally, I can configure that logging level here. And this is affecting the production instance of this application. So as soon as I change this, this actually changed the logging level of the app. And so maybe under normal circumstances, I really don't want any logging. I can turn this all the way down to none. And the reason there's a little bit of lag when I push that is that that's actually sending a request out to the application and flipping that bit. This is all configured and secured using the built-in UAA in Cloud Foundry. And so random people can't just hit this, right? It's checking that I have access to this application. It's sending along an OAuth token to the application, to these endpoints to make these changes. Cool, cool stuff. So Zach, why don't you tell us a little bit about the roadmap and maybe some resources? So I think we're running out of time, so I'll be very quick. But just to give you an idea of what's coming, we're adding a couple of additional management endpoints, including the ability to pull down a thread dump or a heap dump from your running application. Very useful in troubleshooting. We're looking to implement a .NET version of Netflix ribbon to give you more flexibility in load balancing algorithms from your Eureka server, from your Eureka client, rather, and then distributed tracing as well. These slides are available on the schedule app. You can pull them down. There are links in here that help you get started, as well as some additional resources if you'd like to dig in and read some blogs. And if you happen to be attending the Spring One Platform conference in San Francisco later this year, this December, there is a two-day hands-on steel toe course we invite you to attend. All right, and on that note, I think we are done. Cool. Thank you very much. Are there any questions we can answer? There's one right there. Thank you. Does the health endpoint do they integrate with a loggergator? So the health endpoint is slightly different from loggergator. It's integrated directly into the application, and there's some specific monitoring that it's doing there. But we showed you how those actuators show up in the Apps Manager console. And so loggergator does integrate into that. But the health endpoint is separate from loggergator. One more in the back. Is there any work being done on the data store abstractions, like your CRUD interface? Could I just change a configuration parameter and move from an MS SQL database to an Oracle database, something like that? In theory, it's possible. It's not anything that we're actively working on. OK. Are either one of you use spring data stores, stuff like that? So that's a really key feature for me when using spring. I'd love to see a steel toe. Awesome. Will the distributed tracing be using Zipkin? It will most likely be using Zipkin for .NET. There's a question right in front of you. Just shortly, Eureka versus console will both be supported in the .NET version? I don't know about console. Right. So I mean, console is a very heated topic. And I'm happy to talk with you about that after. I think there's a question of how to best run console inside a container on the platform. So that's a challenge. So initially, just based on Cloud Foundry, when the spring team was looking for, how do we solve this discovery problem? Oh, Eureka looks great because it doesn't interfere with DNS, doesn't use anything like console. Now, there's some really cool roadmap stuff that you might have seen talks about today where we have the opportunity for sidecar containers. We're doing things with Istio and all that. So there's a lot of exciting stuff that's going to happen in the next year or so, where I think we're going to have a much better story here in the service discovery. But for today, console in the container, not so great. All right. Well, I think we're out of time. But if you have any other questions, please feel free to come up to us afterwards and ask. All right. Thanks again.


Crops are susceptible to various types of pathogenic microorganisms, which can cause significant economic loss to farmers. To combat this problem, several laboratory-based and indirect detection methods have been developed to identify and monitor plant diseases. These include PCR, IF, FISH, ELISA, FCM, GCMS, thermography, fluorescence imaging, and hyperspectral techniques. Additionally, biosensor technology has emerged as a promising alternative for early detection of plant diseases. This article is authored by Yifan and Ramaraj of Piramasami.


So kind of like I said last video the next chapter in the channel is going to be very different from before but one of the biggest differences going forward is from this point on I've decided to just take a shot and go all in full youtuber and just see if we can make this work now I've thought really hard about whether or not to make a video like this but since we're starting a completely new leaf right now and when I go through the comments and when I see the badges next to your name it's just really humbling to see that some of you guys have literally had my back for over two or three years now I mean two years ago we literally barely had 10,000 subs and now we are almost 10 times bigger than what we were then and to see some of the same faces and some of the names in the comment sections of each video it just really does remind and put into perspective for me just how incredibly lucky I am to have you guys for a community a lot of you guys are just as passionate if not more about helping people save time and avoid needless frustration when it comes to learning how to use the software necessary to bring your dreams into reality and so for those of you who have been here since day one in the blender era and continue to be here today I just wanted to be very clear and transparent about the state of the channel and what my plans are to improve it going forward this video will probably contain more personal information than all of the other videos I've uploaded combined but there's really no way to explain what's going on otherwise so basically ever since I graduated college I've been wrestling with how much time do I spend on YouTube and how much time do I spend bouncing back and forth between other jobs and commissions and consultations in order to slowly chip away at my college debt it's been a struggle ever since the beginning of this channel but as the channel has grown it has slowly become a little bit more manageable like right now it's still not that much but I have essentially gotten to the point where now I make enough to just barely cover all the operating costs of what it takes to keep this channel alive and we are at the point now where even if from here on I never got a single new subscriber at least I could make enough to survive off ramen and continue to make content for the subscribers that I already have just going through YouTube so at this point I really feel like if I push YouTube a bit further then there is a chance that I might actually be able to make up for the commission deficit with more video content now of course there's no way to be sure especially how unpredictable the YouTube algorithm is but the way I see it is if there was ever a time in my life that I went all in one direction it might as well be now worst case scenario I break even best case scenario we actually grow and turn this thing into a full-time gig up to this point YouTube and Patreon combined is pretty much how I keep this channel up and running whatever I make from those two sources I typically immediately invest right back into the channel it's usually just enough to pay for equipment rent supplies and any software tools that help increase the quality of the channel things like substance painter materials textures zbrush 3d assets 2d assets random objects that I think would be fun to see in a tutorial and recently when I've had a bit extra I've started to commission other artists to do things like texture characters for me the latest example is the female on real mannequin I had a lot of fun sculpting but I really didn't have the time to texture her so I hired a texture artist to do it for me and he did a much better and faster job than I would have ever done myself which allowed me to focus more on making content for you guys so everything that I make from YouTube and Patreon really just goes into operating costs to keep the channel running now when it comes to other personal things like tuition insurance gas food those are the things that I would normally take up odd jobs commissions and consultations in order to pay for typically that's been my strategy which was make one video a day and then with the extra time do a quick job for somebody to take care of the non-channel related expenses so going forward from now what I'm going to try and do instead is any money that I make from other random sources like selling on art stations selling on the unreal marketplace for whatever small amount comes from live streams or monetization from Twitter or rumble my goal is to use that money to pay off my student debt as fast as possible and once I finish paying that off all of that extra money will instead go towards hiring a team or other artists to make things for you guys here on the channel things that I know everybody needs like textures a set of RPG characters animations blueprints code or things like a video editor a social media manager discord moderator or someone to clip my longer content into shorts these are all things that I currently do all by myself and I do plan to eventually outsource it but for now I can't really save up money and pay for these extra stuff until after I've taken care of my tuition debt so every month anything extra after operating costs I'm going to try and pay that off first and as soon as that's taken care of all of the extra stuff will go into hiring a team to make the channel faster and better for you guys here now like I said if nothing changed I still have enough means to continue to make content for you guys and I will do so I just want you guys to know exactly what's going on and what my plans are to improve it I'm pretty confident that I'm going to be able to increase the quality of the show you know make the community funner or interactive there's a lot of cool stuff that I'm really excited to try out with you guys especially in the live streams and potentially collaborating with other content creators and YouTube channels but we are now going in for a long-term plan and it'll probably take a few years so we can set things up so I don't have to do every single part of the channel by myself but I really do believe that it's going to be worth it so yeah the gloves are off and I will no longer be looking to do random jobs and commissions because I've decided we're just going to find a way to make this work and there is no turning back we're going all in thank you so much for watching thank you for all your support and as always I hope you have a fantastic day and I'll see you around


playing Clark with head coach Paul Cantabene. Coach, obviously a good second quarter there and some energy in the third. What happened after that point? Yeah, we just got to be tougher. I think, you know, we just didn't, they made a lot of, they kind of bullied us a little bit I thought and pushed us around a little bit and we didn't make a lot of tough plays. You kind of fell apart a little bit there defensively and then slide in a few occasions and we got to find a way to score tough goals in offense. It's the bottom line. We didn't do that in this quarter and so we got to try to figure that out and find some people that are going to willing to, you know, go hard, get polished, score goal and do it all over again.  The turnovers and the kind of the sloppy passes. Is it stuff that you would say this is, it's a mental lapse? Is it the feeling a little bit of the pressure of the opponent? What's going on there? Well, I don't think it's the opponent. We play good teams all the time.  You know, so I think we got to get, we got a lot of things to do. I still think we got a good team but, you know, we're not looking like a good team right now. So we got to do some things better. Trying to find some positives. Connor Halpin, I thought was really good at the dot the night. You know, is it more frustrating when you're wasting effort like that? Well, I thought, you know, I thought Connor played better. I thought he did a good job against a good face off guy and, you know, he's getting better and better and getting more comfortable in that. I thought Justin played fairly well for the most part, made some nice saves. But, you know, we got to play, everybody gets to buy in and I just think we're making too many mistakes and we got to get guys to understand and do what we ask them to do and we're not quite getting that yet. So, but we got another great opportunity next week and see what we can put together and it's just a pretty disappointing effort, I think. I know it's obviously a disappointing effort in the second half, but let's talk about next week and remind everybody about what's going on here and how important it is to get out and check this event out. Yeah, we're really excited about next week. You know, we got 10 great teams coming in and it's gonna be fun and it's just some great games. And so I think the weather's gonna work out as I looked at the forecast. So, it's just one of the better events in college across or across any part of the country to have those 10 games here over two days and it's gonna be a lot of fun and we're excited to host everybody and put on a great effort like we always do here and, you know, just keep getting better so it's gonna be fun. I think, just come out and watch. Mustang Classic Friday and Saturday of next week and Coach always appreciate it. We'll see you back out here on Friday. Thanks a lot. He's Paul Cantabene. I'm Glenn Clark. This has been GoMustangSports.tv.


Hey, from Canada, you guys super American people are gonna love the fact that the Canadian post office really sucks, right?  Now I say sucks, because we're in kind of a small rural area, and who knows, maybe in the city it's even better. Badge? What are your thoughts on the Canadian post office?  Stay out of the Amazon business is what I think, because what they do is they will not deliver any over 35 pounds, but then they go and say, well, it's the wrong address when we got everything delivered there. So I'm not complaining. I think they should stay at the Amazon business, that's what I think. Anyway, today we have an exciting day. We're putting in sub floors, we've got a few pieces of wood over there so far.  We're gonna put all the wood in, we're gonna put heat insulation, you know, foam board insulation and all that stuff.  Oh, it's not a good deal. Hey, Mikey. All right, guys, like I said, today is sub floor day. Michael's getting floored. We got some couple measurements. I'm gonna give him a hand. I'm gonna turn on the GoPro. Let's do a nice time lapse of how much stuff we can get done today. This is the blue skin, high shield, I put the strips up there, I'm gonna drive this sucker to Colorado, and I notice how noisy it is, and I'll put dynamic stream there. And then if we need to add more, we'll just put more in the front, because that's where most of the sound comes from, is there, and then the wheel wells. Yes? Oh boy. Perfect. Bring it in. He doesn't know that I was so good in math, but now he's finally realizing it. This right here is gonna be your hallway, so we're trying to figure out what supports we're gonna put in, because Jacks wants a nice big shower, so it's gonna be somewhere around 30, 32 inches, plus the wall and studs and whatnot, so we're gonna end up with a wall somewhere like right here. So that's gonna be your bathroom. Right.  So your kitchen's gonna come out to here, so your hallway being like this big. That's plenty wide, honestly. So then we want to put probably a center support here for walking, so that when you're walking, you don't get any soft spots now, so we'll throw that in there. We're not looking for RV quality, Mike. No. School bus quality. That's right. There's a big difference. The deep, and you're gonna do 12-volt switches in this wall, so you can do shallow boxes for your electrical, and then your wall will be right here, which means your shower will start right there, so if your shower hypothetically starts right there, your shower will end up being just be like a 29 and a half wide. I think that's okay. I've seen smaller. Sure. We can kind of mock it up a little bit for you to feel it. Yeah.  Okay. And we're talking 31, 30 and a half. What was that? You're talking, you're gonna have to frame this guy out, so we can frame this out like here. Right. So if I did that, you're talking, I mean these are all estimates, but talking estimates here, you're talking 29. Okay, so two. Two is in three inches on my shower, but that's only on your width, because you still have the open space where the toilet is, you know? So I think I would shower this way, right? And then you're shower this direction, because after all, it is a school bus. This isn't a mansion, it's a tiny home. So your wall's gonna be like that, because we need to get the plumbing and diverter in this wall. Yep. So we'll put the plumbing like that. So this wall will be start there, so your shower starts right there, and it has to go to the skylight, which is gonna be somewhere around here, so you're gonna get it up with 29 by 29. 29 by 29. I'll let you know, because you've got to lose it an inch and a half for your wall. I think, I think it's gonna work. I'll just have to eat less tacos. All right, ladies and gentlemen, this is kind of what we're dealing with, although we need to put a little two by four in the middle. Mike is such a genius at building that he's like, wait, we messed up! So we had to basically cut out the area that's gonna become the shower, and yeah, and so we're putting these things where the wall goes, not necessarily every four feet. Really? No weight. I'll explain for people.  Like, this isn't a walk area. The walk area is where we don't want the little flexes in the floors. So do you want to explain what's going on? Yeah. So Jack's here once. Would you want a queen's full size bed queen? Well, queen. We're going for a queen, but it's foams we can cut. But the idea is that... Or squeeze it. Yeah, or squeeze the foam. So the idea is that this back wall, whatever molding you put, plus the bed, plus your wall to the wheel well, you need to know that in your subfloor, because Jack's what we're doing is we're putting a sunken tub or shower base. So his shower base is essentially below the subfloor so he gets that extra inch and a half headroom. Yeah, for two reasons. One, I'm a tall dude. If you guys don't know that in videos, I'm a six foot one. And also, to keep the water in, the water's gonna, we're gonna tile down so it keeps, you know, gravity. So the problem is that you need to kind of know, you know, there'll be plywood, you know, up to here, and then this is his actual shower. So you need to kind of know where this beam's going now before you even start doing it. The plan is we have this skylight up here and the wall, the plan is the wall's gonna go pretty much just like that. Now most people would probably say go grab a level or a plumb bob, but the problem is we're on an uneven bus on a suspension where nothing is actually square level. So then we have to figure out where is the bottom of the shower base gonna be to actually be able to make this sunken tub in the correct spot within the subfloor. So when you're building buses, it can be really difficult because you don't want to corner yourself at such an early stage. Unfortunately right now we're not in a super level spot. You already said we're going to Colorado, so there we're actually gonna be on a, you know, a concrete slab. We can level the bus out and actually get, you know, a better measurement. So right now we're kind of just trying to work with what we got, but essentially this is Jackson's shower, this space right here. That to me sounds good. The toilet's gonna sit on top of this thing, the wheel well, and if I need to, because I've got broad shoulders, so if my body is like this, sideways, it's a big deal.  It's not a mansion, guys, so you can't have everything. You have to compromise. Yeah, and for anyone who's wondering this space, the shower base is probably gonna end up being around 29 inches by about 31 inches.  If you've seen my bathroom, it's gonna be pretty similar to that. He wants a similar design. Dude, if you guys haven't seen this bus, you gotta go check it out. Navigation nowhere. It is my favorite bus on the internet, my personal opinion, the best one. So having Michael is a huge help because otherwise, you know, you could put something in and then have to backtrack, which I know I did in the first one. So otherwise, I would say maybe mark things out in advance, tape it out, do something because he's done buses before and he knows what to look for. Gentlemen, boys and girls, fist rise on the subfloor. This is the insulation so far because we're dealing with the elements up here in Canada, Canada, A, we got the rain coming. So we're gonna put this plywood over and then get back to work. All right, there we go. I went against Michael's recommendation, preferences, I screwed him in. It's only because humans are a creature of habit and I did it before and I'm not saying it's the right way, but I'm doing it again. And Uncle Dan used to have the story about why, when you make split pea soup, you know, it's like, why do you put the ham hawk in there? And so the last generation was like, I don't know why we put it in there. It's because my mom did it. You go back another generation, I don't know, it's because my mom did it. You go back another generation. Well, that's because it was during the war or we couldn't cut it or the bowl, yeah, the cooking vessel wasn't large enough. And so you just, you know, put the whole thing in there or whatever.  But anyways, creature habit, we're doing it. Michael, are you going to do another video on how not to screw on the floor on your channel? Yeah, you should do that. Cause he's got great information, but I didn't listen to him on that. Yeah. Yep. It's still going to run. Yes. Guys, check it out. Six or seven weeks later, I don't even know at this point, we're getting in the floor today. That makes me really, really happy. Look at that guys. Got like Shooter McGavin over here. But like for cutter, we got cutter, cutter McCutter right here. Look at this. You got a little tongue in groove and we're going to, we're going to get that right in there.  Check out in the shower guys. What do you think? Do you think this is big enough for me? Six foot one. Dude, broad shoulders. I think it will be.  We're going to bump that out.  We'll give it like an inch for, because the walls aren't straight plus the molding. So we'll go 25 and a half. Your cabinet will come with your closet cabinet right there. So that's your hallway. Cool. That's plenty wide of the hallway.   Like you don't have to go sideways. This is plenty of space. All right. It's a 30, 31 inch hallway. So that's almost, that's like residential wise. It's not bad. It's not code, but you're not going to do that in a bus. All right, guys, it's coming together. We've got the floor done.  Also, well, disappointed. I don't know, did I mention that already? I think I did. Puzzle? The package came today and it needed a credit card, because apparently in Canada, you have to play customs, even though I'm shipping something from the US and I'm US citizen and I'm bringing it back to the US. Go figure. So we're trying to get as much finished as possible. We've got rain coming. This is where we are. So essentially, we're going lengthwise, right? This is where the second piece, second lengthwise piece will hit. It's at 16 feet. And this is how we're doing the subfloor. Very sturdy and secure. So if you're stepping on, I mean, all of this is super secure, because it's super thick, dense flooring. So foam board insulation. Michael's going to cut some stuff up real quick.   Michael, that's so much. But we're putting in pieces three and four. This is very exciting. Look at what a tight squeeze this is here. Cool. That is a tight squeeze. Damn. Then what you do, Michael, you want to demonstrate. On the other side, just to get it nice and tight. Just whack it into place. I know, right down the middle. I mean, that's like, that's great. That's within an eighth of an inch. You know, give or take that way. So I'm so excited. I'm so excited.  They're definitely going to get a phone call. Because if you pay for something, you should get something, right?