Well, welcome back to Azure FunBytes. My name is Jay Gordon. Got a little rough start there, but hey, things happen when you do it live. Welcome back. Hope everybody is doing great. Once again, we've got a great show for you today. My name is Jay Gordon. I am your host here on Azure FunBytes where we talk about the people, the products, and all the things that come together to make up an amazing Azure experience. This week, we're going to be talking about what I just tried to show you a second ago, and unfortunately, I made a mistake. I'm going to fix that right now. We are going to be talking about SignalR service, and what exactly it does, how you can build real-time applications with it, and hopefully add this into your suite of software that you use. Let's try taking that a look at that again. What is the best way to easily add real-time web functionality to an application these days? You know, for things like chat, gaming, dashboards, device-to-provice communication, or a myriad of other instances that are made infinitely better with real-time communication. We think it's a little bit of genius called Azure SignalR service for Microsoft. Azure SignalR service is specifically designed for those creating applications that need to pull servers multiple times a second for each connection, web, or mobile, who prefer to spend their time working on their core business rather than managing backend infrastructure. And the best part? It's fully managed. No more developing plans for outages, scalability, load balancing, security, or even staffing to address all this stuff. All you have to do is provision it and turn it on. Oh, and because SignalR service is developed for Azure, it works seamlessly with its other platform capabilities like Azure Functions, for example, locally or around the world. Want to see for yourself? Head on over to azure.com slash SignalR and try it, free. You'll be up and running with just a few clicks with Azure. Hey, I got it right that time. Sorry about the first roll around, unfortunately. Sometimes when you do it and you do it live, weird things happen. So, hey, welcome back again. Like I said, what we've got today is a great show on that very subject SignalR and to help me do this, to help me get this right, I have Chris Norring. Hey, Chris, how are you today? Hi there, Jay. I'm good. How are things? Great, great. Thanks a lot. So you're a senior cloud advocate, correct? Yeah, that's correct. I'm a senior cloud advocate on the academic team. Awesome. And so that means you're working with people from places like universities, schools, to make sure that they're able to take on these different types of subjects and bring them into the fold. So as they continue and they start their careers, they've got some sort of background, am I right? Yeah, you're correct, Jay. So what's interesting about this crowd of folks, right, is that they're very much in the learning spirit, right? So we try to catch them when they are at their most passionate, right? So they've just learned how to program, they wanna do more and more and whatever service that we can showcase in front of them that's gonna make their life easier and give them real job skills is what we wanna teach. And I believe that Azure SignalR is one such service. Wonderful, wonderful. So one of the things that we'll be talking about is how we can build real-time applications using Azure SignalR. We'll look at implementation of the service that Microsoft Azure provides. And so I think we've got a really jam-packed kind of hour that we'll get into. And I just wanted to remind everybody a few things before we get started, if that's all right, Chris. We'll do it real, real quick and then I wanna ask you a question about yourself. Reminder that if you're here with us today on LearnTV, you can go ahead and find all the notes for today's show. They're up there on the left, or I say the right rail. If you have any questions, you could put them in the chat on aka.ms slash LearnTV. Or you can use your native chat if you're using Twitch or YouTube, all fine. The other thing I wanted to remind everybody about, which I think is really great is Azure open source day and open source. I know Chris, that's near and dear to your heart. We've got a great event coming up that you can take part in if you wanna register now. It's Tuesday, February 15th, 2022. You can go to aka.ms slash OSS day AFB to get more information. So I think that kind of goes through my little run through in the beginning, Chris. So I wanted to ask you a question before we get into the subject because I always like to do some context setting about my guests. And the question is, how'd you get here today? Not physically, but here at Microsoft. How'd you end up in the role you're in and doing the things you're doing? Yeah, Jay, that's a really good question. So I started my career some 15 years ago, plus now I think I started developing applications using .NET web form for the technology. I mean, I'm from Sweden, right? So I spent most of my professional career in Sweden. So some five years ago, I decided to move over to UK. So now I'm based in London. Now, throughout that journey, I had a chance to try out various tech stacks. So I've been trying .NET, Python, and as of late, I've been a lot on JavaScript, but I have definitely not let go of .NET. So I'm definitely doing that as well. And I would say it's as part of being a .NET developer that I first come to hear of SignalR. So yeah, I've taken a geographical journey as well as a technical one to be here today. Very, very cool. And so we'll be learning a little bit about SignalR today and how that implementation works. And I wanted you all to know that there are some great resources, educational resources I know Chris has worked on with Microsoft Learn. So if you want to take a look at, there's this introduction to ASP.NET core SignalR. You can go ahead and take a look at that URL. And then there's also another great, a great module that you can take a look at, enable automatic updates in a web application using Azure Function SignalR service. So all that is in the show notes if you'd like to go ahead and give that a shot. But wait till we're done here, because we got a lot to talk about in just a short amount of time to do it. So Chris, I want to get into today's subject, which is SignalR and Azure SignalR service and how it all kind of fits together. And so the main goal here is building real-time applications, if I'm right. And so why do I need them? And are there some good use cases that you can mention? Yeah, so I think that's a very interesting question, right? Because I think most of us, when we think about apps today, we might have an app, it might have a database, it might have a service layer and some kind of front. And we are used to just, when we start the application, it loads some data and we might input some data and then we press a submit button at some point and that data ends up in the databases. So how do we move from such an app to real-time application? Well, think about it this way. Think about it as data that you want to know about when it happens, rather than you having to hold for it with a polling interval of 30 seconds or five minutes, it's actually telling you when it's starting. So in a sense, imagine NASDAQ, for example, do you want to know about the stock markets? You want to know when that stock is actually dropping or it's going up because you either want to sell or you want to buy or let's say you have a game. You want to know when your favorite player is joining World of Warcraft, for example, or you might have a chat application and you want to chat with people so you definitely want to be told they are here, they are ready for you to speak to them. So there are definitely scenarios out there where real-time capabilities makes a lot of sense and you might want to shy away from a low-grade solution as polling because polling isn't really nice because it's not really real-time. It's just you saying at a regular interval, I want to do this call again for the database and there may or there may not be some new data there for you to have.  And one of the things I know that we'll probably need to do is to get points on a map sent back and forth and updated in our application. And I'd imagine that's a great use case for what we consider real-time applications. Am I right? Yeah, for sure. So imagine you have ride-sharing, right? And as you pointed out, you have a map. You definitely want to know what that driver is. You can look at that map and you see that driver approaching and maybe you even want to hear from the driver and say, hey, Jay, are you there? Can I actually pick you up? Now, at that point, you can define it so that in SignalR, certain messages are being sent as there is some kind of data added to a database, right? So let's say that those locations on the map is added to a database. You add a trigger on top of that and you want that database trigger to say every time a new insertion of a X and Y location is being added to that database that is sent as a SignalR message. By having a SignalR connection, you don't actually have to pull for that.  So you're sitting there in your application and boom, to come data and you see that little plot on the map just moving around. So that's how ride-sharing would work, right? And thanks to Azure SignalR, you don't have to worry about scalability. You don't have to worry about performance because that's our job. Absolutely. And so one of the great things that Azure does is we've got so many ways to actually implement services that will replace what are normally traditional server models where you would have to create a virtual machine and then work with that or set up a server. And so this is a page from that doc that I just showed and there's some great use cases that are all up here, high-frequency data updates, like you mentioned gaming, voting, dashboards and monitoring. So if we've got a number of different services and we wanna create our own dashboard, really great way of using it, chat, especially if you wanna do some live chat agent bots or something like that, locational map like we just mentioned, real-time targeted ads, collaborative apps, push notifications, real-time broadcasting, IoT and matter of fact, real-time broadcasting. Here's a great example of what we're using right this moment, having a real-time application that we're getting messages back and forth, IoT and automation. So these are all relatively understandable use cases. And so I have another question for you, Chris. And then I'm gonna give you some space to start showing me a little bit of what you might have brought to the show today is can you describe the architecture and what major components are involved in implementing Azure SignalR from my app? Yeah, for sure. So I do have a little slide deck. So we're gonna shift into there. I am sure, right? Great. So I just wanted to show you some components that are involved. So depending on- It's a little small. I'm sorry for interrupting you, Chris. It's a little small. You might wanna bring it into, yeah, perfect. Yeah, that's good. That's good. Awesome. Much better. Yeah, so one thing we need to keep in mind is that we need some kind of Azure instance provision, right? So we need to do the work. We need to go into the portal or we need to use Azure CLI and we need to create an instance of Azure SignalR service. Now that service is our connection point and it will handle all our connections, all our messages and keep track of everything, right? And so once we have that provision, what's important to know is that we have a client. So we have a client being a player. One of the first things the client do is to talk to that SignalR service in the cloud. And once it does that, for the first time it does a handshake. So it's talking to the SignalR service and say, hey, I'm Chris, I want you to know about me. So at that point, the Azure SignalR service sends back a connection object. Once you have that connection object, you essentially have a persistent connection, right? It knows who you are, you know where to go. And when you have that connection, that means that any kind of messages that you're gonna send from the non, you know exactly where to go and any kind of messages meant for you, it knows where to send them. So in a sense, depending on what architecture that you select, because there's more than one, this is the meat of the architecture. Now, Jay, you had an excellent documentation page there that kind of described three different architectures. And depending on if you go with .NET, you're gonna use an architecture involving hubs. So that one is a little bit different. But I thought I'd show you the one that is serverless because that's your second choice. Now, the idea of having a serverless connection is that you are building an Azure Function app and having at least two endpoints. One endpoints for that handshake and at least one endpoint I will handle in a type of message. So if you were to send a message to all the other clients that were to listen, you would need an endpoint for that. You definitely need a negotiation endpoint as well. So the idea is that you, from your client, talk to the Azure Function app that in itself talks to Azure SignalR instance in the cloud. So yeah, so from the way you stand as a client, you are only talking to a normal backend but it's being reactive in the sense that it is using Azure SignalR. So if you know how to build a client, if you know how to communicate towards a Azure Function backend, there's not a lot that you need to do at this point. So this schema here is showing how things can work. So the idea here is, if you see this picture, is you start off by connecting to your Azure Function app. You get that connection instance back in third step. And if you look at here on the right side, we can see that what's happening is that the middle client here is sending and the two other clients on the left side and the right side is receiving the messages back based on the fact that you go to the Azure Function app, it goes to the cloud and the cloud is sending what's called an outbound message that will be sent to the other clients. Yeah, so that's a little bit about the architecture. But yeah, I wanted to reiterate one more time about the documentation page you showed because you showed supported runtimes. And I think it's important to say that Azure SignalR can really be used by anyone, right? So if you're on ASP. Yeah, so you are on ASP.net. You definitely have a method and architecture to use. It's a bit different than the one I just described. But if you are on C sharp, if you're on JavaScript and Node.js, if you're on Java, if you're on Python, you would be using an Azure Function instead. But you also have the third option, which is a REST API. So if you're using Rust or Go and it supports HTTP, you can actually implement SignalR using that. So you have a lot of options of how to implement SignalR. So which MO that you choose forward is really up to you, right? Absolutely. And so obviously you're going to be using the service within Azure. It's like all other services with Azure. There's money associated with it at some point. And so what pricing tiers exist and when am I being billed for this service? Yeah, that's an excellent question, right? Because we all hear that something is free to begin with and then it's not so free. And we kind of want to know the trigger points for that. So let's talk a little bit about billing, right? Because when you create that instance, you do so selecting a pricing tier. And first off, when you're starting off, you might select a free one because you want to see if it works, right? But there's also the standard tier. And if we have these two alternatives here side by side, we see that with the free tier, it has 20 connections to start with. You can send as much as 20,000 messages per day, which is quite a lot if you're just testing it out. If you are on the standard one, you see that you are easily in the millions. Now, as for your second question there, which is an excellent one, when am I being billed? Well, first off, you got a monthly cost of $29 a month. That might vary a little bit per region. So I definitely encourage you to go into this pricing calculator here so you can see exactly how much it costs for you and in your currency. But as for being billed, one thing you need to keep in mind is something called outbound messages. And the outbound concept simply means when I go from the server and I go towards my client, that is counted as outbound. When I communicate from client to Azure, it's actually inbound. So if we understand that the outbound part is when we're being billed, there's another factor that also affects your billing and that's the size of the message. So if your message is four kilobyte big, for example, it's counted as two messages because the limit per message is two kilobytes. So imagine that here, that you're sending this four kilobyte message. It's being sliced up in two different messages per client, but they will arrive sequentially to each client. So two messages here, two messages there, two here and two here. So you sending that first message to three clients plus a server is gonna be a count of eight messages. So if we just head back here to our free tier, we can see that if I were to send that message in that situation, I can see that I need to deduct eight messages from those 20,000. So if I wanna know the rate at which I'm burning my message account, it's kind of good to know how it calculates. So if I'm being very, very wordy, I mean, four kilobytes in text, that's a lot of text, right? But if you were to- It sure is, yeah, yeah.  So it's kind of good to keep in mind that I just wanna connect again to what you said about that ride sharing app. You're more likely to send the X, Y and Z coordinates, right? You're not likely to send a picture of the driver every time.  But I'm thinking it's kind of good to know the outbound concept versus the inbound and the message size. And also that you have like a basic cost per month that is what you will be paying for. But if you need more than one million messages per day, then you're probably a very, very big company. And you see that if you wanna scale that, if you want more units, you can definitely do so. But you see for every unit, there's a thousand connections. So imagine that you and me, Jay, we are talking to 998 other peers. And if I'm in a ride sharing app like Uber or Lyft or whatever, right? You can imagine that a thousand cars, well, yeah, sure, they have more than a thousand cars. But if I'm just starting out in my basement with maybe 10 cars or 20 cars, I can definitely use Azure SignalR. I can most likely get away with this $29 to start out and I'm not gonna be robbed, right? I don't need to go to a venture capitalist and ask them for millions of dollars. So hopefully you feel, yeah, go ahead. I have this image and I wanted you to take a look at it. It's from one of the documents, which is actually getting started with the real-time apps. And there's this interesting kind of architecture diagram. And I was wondering if maybe if you can take a second, kind of go through the steps that we have here because it looks like our application that what's presenting is up at the front. So where would we find SignalR in this particular kind of architecture diagram? Yeah, so this is a really great picture because it's showing us two different scenarios. One using web sockets and the other one, AJAX Long Poland, right? And polling is the way that we use to make sure that stuff is perceived as real-time before we had sockets. So what's great about SignalR is that it's an SDK on top of that, right? You should be agnostic to whether it's actually able to use sockets and if it can't use sockets, it will default back to polling. So the great part about SignalR is that it encapsulates whatever real-time approach that you want to use and gracefully degrades to whatever features that you have on your system. The important part for you as a developer is that you shouldn't care. So looking at the left side, that's your best case scenario, right? That's your device supporting web sockets. And yeah, you can definitely say that, yes, it's transporting messages. It's using a persistent connection API through the SDK. And yeah, you have your web browser application and looking at the right side, we see that you are getting pretty much the same thing, but it's using polling, right? So yeah. And if I'm right, there's three different types of ways of doing this with SignalR. I know that it's like long polling web sockets and there's one more if I'm right, isn't there? Yeah, I believe the, let's see here, I don't want to mix things up, but I do believe the hub approach might be a third one because I know .NET intrinsically uses a different version because .NET was the first runtime to kind of adopt SignalR and then it kind of moved into being more agnostic, usable by JavaScript and Python and all those other great languages. So we're going to be talking a little bit about the scaling aspect and I thought this was a really good document with an image to show as well. The different types of way of actually hosting SignalR and so obviously you can do self-hosted, which also means that you're gonna actually maintain the underlying system, the operating system, the required software to actually run SignalR or you can use the Azure SignalR service, which as you described, it's a subscription-based service, it's run as a platform that you can implement as part of your application architecture. And so one of the other questions I have for you before obviously you can show us is how does it scale and can you describe how I would scale it and what I need to know? So depending on approach you're using here is a different kind of scaling, but I think it's a great picture that you showed. So the app service, we talk about something called point of scale, right? So the app service will be the point of scale. So if you need X number of instances of app services that is running, that's how we would scale. Now, normally that's built into a pass or platform as a service, meaning that you don't really need to care about that point, right? I mean, you can have an app service run across regions and have it scale as much as you want. The only thing I guess you need to keep in mind there is the cost. I believe that, I can't remember right now how app service is being built, but I think there are different things like how much data you're using probably. I don't think you're paying for the actual scaling, but you're rather paying for the messages being sent across, right? I do believe that there's some instance cost. Yeah, there's a couple of different SKUs that are like a basic standard for production, premium enhanced, isolated, things like that. There's a few different levels that get built, I believe by the hour, so pay as you go for the amount of time that the actual application is online. And so it differs obviously from serverless and a function because those are always being maintained. They're always online, they're always active, whereas for their functions, which I know it's funny about, normally they're run and accessed when it's some sort of triggering process occurs. So I think we've got a little bit of understanding about what SignalR is, how it is, why it is. And I'm curious if you can maybe show me a little bit of how we can do the actual implementation. Yeah, 100%. So let me just go back and share some more slides because I believe I had a video. It's always good to have a backup. Let's see where we are. Yeah, so here, what we're looking at here is a backend project. I'm not sure you're able to see, but I can explain what you're looking at. So here we have generated an Azure functions application. Now, as we all know, we can generate that for whatever runtime we want, which could be Python, could be for .NET C sharp, could be Node.js, even PowerShell. Now, what's important to look at here is that we have two different endpoints and the way that an endpoint is defined in the Azure Function app is that we usually have a director with a certain name. We have a function JSON and we have some kind of code file. Now, this is the approach used by a bleep Python and JavaScript. I think C sharp is doing this a bit differently by having one file with a lot of functions in it. But regardless of which, the negotiate one is interesting because that's the thing that you at least must have. Now, looking here, we see that we have zoomed in on index.js, which is the code file. What we see here is that if this one is being triggered, we see that what it does is that it assigns something towards a response object and its body. And what it assigns is the connection information. Now, the negotiate endpoint is being called when a client connects towards your backend. Now, we'll show this by just running this video. So what we're looking at here is that we first start off the backend. So we have that up and running. That's great. So we have a backend. And what happened here, you might not have seen it, was that the first thing that happened is that I started a browser and when I start my client, the way that the client is written is that I have a piece of JavaScript code that tries to connect to this, the first thing it does. So it goes to wherever the signal or endpoint is living. And the first thing that happens is that it hits a break point. Now, once it hits that break point, what I want to convey back to the client is that here you have a connection object. When you have this connection object, you and me, we know each other. We know how to talk to each other. I know how to send you messages. You know how to push messages to me. So if we go past that point, we see that we can let go of that break point and we can return that back to the client. And once we do that, yeah, let's see if I can fast forward this a little bit. There. We are in a chat, right? So I have opened up a chat. I am Chris and now I'm fully connected because what's happened at this point is that my client that I started up connected to my back end and once it connected to my back end, everyone's happy because the client has gotten this connection object back, right? Now, I want to start a new client. I want to talk to you, Jay, right? So I have a second client here that where I point out the back end and I give you the opportunity to input your name and same ML happens again. In this case, you go towards your back end, the same back end, and you also receive this connection information. So you're also connected to the signal or service and we are able to talk to each other. Now, at this point, I'm adding a message and I'm saying hi, Jay. Now, at this point, I'm not reaching the negotiate endpoint anymore, but I'm reaching a different endpoint. I am reaching an endpoint called slash messages. So if we look here, this is a different endpoint as part of our Azure Function app and it does a different thing. Looking at this code here, what's going on is, if you look here from line 10 and down, is that I'm going to end up producing a signal or message and we can see that as part of line 12 here, where we set the target value and we call that new message. Now, the value new message, this is something I choose. I can call this whatever. I can call it as me sending message to Jay or here's your coordinate for your app or here's the stock market information that you want. I choose to call this new message. So this is an agreement that the back end and the front end needs to have with each other. We need to know what message is that we're going to send to each other by the name of the custom event. So now I have started the contract from the back end. I call this new message and I give it the value and the value is part of the arguments here on line 13. So that's great. You are answering back to me and saying hi back, Chris. So at this point, at this point, hey, Chris, the breakpoint is being hit, right? And if we look at the breakpoint here, we see that hi back Chris is part of the text property and we see that the sender is Jay. Now, what I want to do at this point is to go to line 10, where the message is actually being sent via Azure SignalR and that thing is going to hit and I'm going to receive that on my client then. So what I want to do is to let go of the breakpoint but I want to investigate in JavaScript how come this works? Well, it works because when I start my connection object, one of the first things I do with my connection object here if you look at line 127 is that I have initiated a connection object. The first thing it did was to go towards that back end and it returned a connection object. But on line 127, I see how it listens to something called new message and this is where I said that the client and the back end are in agreement what they call this because I know that the back end is going to send something called new message and when that happens, I will know. So when new message happens, it will invoke a function and say, hey, Chris or Jay, depending on who gets the message, here's something that I want you to know about. So new message here is a function. It takes message. This is the message that comes from the back end and this message is being added here on line 147 to something called data, which is an object that I associate with my JavaScript application. Now, in this case, I have a JavaScript application that's a UGS application, but you can definitely use React or Svelte or even regular JavaScript to make this work. So on line 74 here, I'm setting the data property as part of my view application, which means that whenever this data is being set, the data is being updated as part of my UI. And if I look at my UI code, it from line 40 and below, what it does is that it loops through all the messages that I have. So this means, Jay, that when you send me that message, it will affect that data property messages, which means that my UI will be updated because that's how view and any kind of reactive front end framework works. And if we go through this little bit, we can see that when I let this go, I see that the message is appearing. And this is all thanks to how my client application works. It listens to that new message. It says, thank you very much, Jay, for sending that to me. And now I'm going to update the UI. So that's really how the flow would work with me having a client that starts off by connecting. Once I connect, I sit there and listen and I wait for Chris or Jay to talk to each other once they do. My client's going to say, ooh, thank you very much for that new message. I'm going to better update my UI application. So I'm actually going to take you from this demo and I thought I'd take you through all the flows. So we understand, well, Chris, what are all the bits? What do I actually need to do? Can you remind me again? So I'm thinking I just take you through all the steps that I went through to create this application. First thing I did was I went into a portal asher.com or I could have used Azure SignalR. First thing I do is to type signal. That means it's going to show me the services here at the bottom called SignalR. I'm going to select that. Once I select that, I hit this Create button. Once I hit my Create button, I'm getting this form that I'm sure most of you are used to seeing by now. I need to fill in some things. I need to fill in my subscription, what I call this resource, what region I'm in, because it matters how fast these messages are going to show up. And then I need to select the pricing tier, which is either free or standard. I can change that if I want. And I need to set the service mode. Now, if I'm using the serverless version, this is that's something I need to keep in mind. But if I'm using the ASP.NET version, I don't need to do anything here. But let's say then that I provision this instance, I can then go in afterwards in my provisioned resource. I can go into the Settings property and I can set this serverless property, which means it's set up to work with my Azure Function app. Now, once I have my Function app, sorry, once I'm done there, I can go to VS Code or Vision Studio. I can generate my Function app. And then I need to set up this slash negotiate route, which I can do again via VS Code and just generate a new endpoint. What's important here is the bindings. Now, one piece is important. One, I need to reach this via an HTTP trigger. That means that my client will need to reach this via request. If you remember seeing from the browser, one of the things you were asked in that modal is where do I need to go? In my case, I said you're on localhost 7071. So that's great. But this type here that says signal or connection info, this is that decides that what's being sent back once I connect the first time is the connection info for signal R, which enables that the client on the back end is now handshaking. And yeah, once that's done, I need this code. It's not a lot of code. All I need to do is just make sure that the response object's body is being set with the connection info and send that back to the client and they are connected. Now, the other piece of endpoint that I need at least one of is I can have many types of messages. If I have a ride-sharing app, I might have one endpoint for sending chat messages, one for sending XYZ coordinates and so on. But this endpoint is doing messages. So it is being triggered by the HTTP. If I want to talk to UJ, if I want to send a message, I send a request towards a certain endpoint slash messages. And the output here is a response of type signal R, not signal R connection info, but signal R. And this is how signal R knows what kind of message and it knows to tell all the other listening clients. Now, how we handle the incoming message is the return bit here where we say target is of type new message and the arguments is the value that I want to send back. And yeah, one thing that you definitely need, otherwise this won't work at all, is that you need this piece of information in local settings, JSON, when you're doing things locally. And that means that you need the Azure signal R connection string and this is a connection string that you can get from the portal. But as we know, once you deploy a function app, you can synchronize this with your app settings, right? So everything in here could be moved over to your app settings tab that you have on your resource. Yeah, so that's how all the code works and how it works via the demo. We talked about some learn models, I believe, Jay. And you said, yeah, ride sharing apps, great. But you could also have a finance app, right? So I thought I'd show you an example where you can take that finance app that you don't like, you built it circa 2003 maybe. It worked at a time, but now it's 2022. I got that, right? I was about to say 2021. Imagine though that you're still working on that same awesome finance company and you're being tasked and someone tells you, Jay, can you update this app for me? It's working by polling. And you're like, oh, God, I don't want to go in here. I don't want to fix this. But then you hear about Azure signal R and you're thinking, sweet, I better try that, right? So I go in here and I learn all about how to use Azure Function and I set up my function app just as I mentioned. And what I do is also to make sure that I have a database insert trigger on one of my endpoints, which means that if someone who works on the finance department suddenly have access to it and can update that database, I have a function app that reacts when something is being inserted in that database. And once something is being inserted, then it can actually push via signal R to the client. And suddenly you can delete all that code who does that polling behavior. And instead, you've just set up Azure Function by just writing code that probably took you at most an hour, I think. And you probably spent 50 of those minutes looking at docs and you're actually writing code timings is probably somewhere around 10 minutes. So yeah, if you know how to use this, if you've got some awesome docs resources that you showed everyone, Jay, I believe that you can take any kind of legacy app and feel really good about it if you already have that capability. Very cool. All right. So I wanted to go into the portal for a second if you don't mind, Chris, because I've actually created one of those services that you kind of showed us just a moment ago. And if we could just kind of take a quick look, let me make it a little bit larger for our audience. So when we create a signal R service, we get a fully qualified domain name of where it's hosted here locally. And we can see that we've got some tools and SDKs that come along as well as some monitoring. So we've got like two sections of SDKs right here, the control plane for our standard languages that we would want to use, and then the data plane. And I'm not too sure about the data plane because I can understand the control plane. Do you want to talk to me just for a second? About what that data plane is and how it's accessed? Yeah, for sure. So with a client SDK, for example, on the data plane, what that means is that when I'm building stuff in JavaScript, I have an SDK file that I'm pointing to that lives on the CDN, which means that what that SDK will give me is a connection object that I can point towards your backend that you've set up there. And it will also have the ability to send messages also and listen to messages. So connect, send, and listen, which is pretty much the three basic functions that you need on the client side of things. So if you were to click that client SDK, you would actually come to the implementing JavaScript code. Now, as for the other piece in the data plane is the service SDK. Now, if you're using an Azure Function app, this is a capability that you're going to need. So you have a capabilities file as part of your Azure Function app. That enables you to set these various triggers, right? So remember how I said that there was a inbound connection info of type Azure SignalR? That's part of the backend and the data plane or that you wanted it to answer with a SignalR thing when I sent the message. That's the other piece, right? So, yeah, it's three pieces that you need to remember on the client and there are two pieces that will give you those capabilities on the backend. And so I know you mentioned connection strings. I was just going to say the next thing, I know you mentioned connection strings and right here on the left rail, we can actually see that we can go in here, we can create a connection stream for our client endpoint, set up an access key, managed identity, so if we don't want to manage, we can use Azure's AD for our AD application as well. So we have a client ID directory, so I'm guessing that this is a service principle that we're popping in here. And the other thing that I like is that on the left rail, there's quick starts. And so I wanted to maybe step through this a little bit with you if that's okay. Yeah, sure. So the first thing we need to do is use SignalR and the configure services. And I was curious if you could just give me a little background on what this particular code is doing. So this is .NET, right? So what you're inside of is a startup application file. So one of the first things that happens when you start off a .NET application, it is running this file and is looking for configurations that you might have in your environment variables or as part of your secrets. And the part that's important here is two different methods. First, configure services. This is where you tell it to have the capabilities of Azure SignalR. So if you look at configure services, you see that it's doing add SignalR, add Azure SignalR. Those two lines are very important because it gives your app the capabilities. But at this point, you've said this middle where exists, but you haven't actually told it to use it. That's the next step. That's what happens in the configure method. Now, if you scroll a little bit in the configure method, that's at the bottom of the screen, you see that it's doing something very interesting. It's calling use Azure SignalR. This is where you are showing intent. I mean, if you in configure services said, this is a capability I want you to have, in configure, you're saying, I actually want you to use it. And as part of that, I am setting up an endpoint. So you're setting up a hub. This is using the other ways of doing things with as a speed of net. Remember if I said this is the non Azure function version. But what you're doing is to setting up a map hub chat at slash chat. So you're setting up a backend so people know where to go to chat for messages. Now, what we're looking at here is, first off, how to broadcast messages. So this is what you're doing here is to send a message. So you are giving it a name broadcast message. You could be calling that anything. This is just a chosen string of your choice. You could say, Jay is sending a message. The important part is that the first parameter is the name of the message. The other two parts is things that you will need to send the message across, like name and message. Now, echoes are not something that you're being built for, but it's something that makes sure that there's like a keep alive function. So that's not a ton of code, right? It's only showing you the bare minimum of what it needs to set up the hub. And if you remember that we talked about a hosting option where you are doing stuff in app service, this is the code that you would need on your backend. This is the dotnet application that you would need to deploy to leverage app service. Now, with that said, you still need a client that connects, and that's what happens in step three. So what you're doing here is you're first trying to connect to it. So bind connection message. We can see here that our connection is interested in listening to certain messages. That's what happens on connection on. So it's listening to broadcast message, and it's connecting a message callback function. And the other connection on is doing an echo, and it's listening to echoes. And if I remember correctly, echoes are to make sure that things are still there.  Why are you not here anymore? Answer me, right? So you kind of need that one. If that one suddenly times out and says, I don't want to talk to you no more, you would know from the echo that, hey, sorry, the backend is up and left. So yeah, if you see that connection being created with bar connection equals new hub, what you're doing here is directing it towards where do I actually find my backend? You're telling it that it's at slash chat, and then you're calling build, and that means that you now have a connection object. So now what's happening is when you call connection start, a couple of lines down, is that now you are initiating that connection from the client towards the backend and said, hey, I want to handshake with you. I want to say I exist, right? So when you tell it yet you're exist, just like the Azure Function app architecture, it's going to send you a connection back, a persistent connection that opens up this tunnel between client and backend, and they're going to say, I can send message this way and you can send message this way. So it's completely open. It's not like the usual stateless HTTP thing here. It's a socket connection, right? And should that connection go down, you see that we have this catch function that's going to say, hey, something went wrong in the backend, just disappeared. And send it to the error log, and if you're taking error console messages with your error log, you can go into that, you can determine what cause, maybe there was some sort of transmit failure somewhere along the way. So we got a question in, and I think that it's, we might have just touched on it, but I want to just double check. Phil wants to know how is authentication handled? How do I validate clients? Is it via a function app, of like, anonymous keys, OAuth2? Yeah, so I think that's an excellent question. As we, in function app, we can use Azure AD, but we can also use the, in the function app, right? You can also use an API key, but I would say this, you don't want to run your own way of validating that user should be here, right? So you probably want to use something like Azure AD, or you want to use OAuth to support that. Now, because of the way that the Azure function app architecture is set up, it's set up to work with, for example, Azure static apps. And that's another service that works really well with Azure Signalor. And the idea there is to have a client on the front end, and the backend that would be a function app. When you deploy those two together, right? You get this Azure static app. And as part of that, you can leverage social auth, you can leverage Azure ADs. So you have a lot of authentication options. So I would say, if you go down the route of using Python, C sharp JavaScript, and you don't use the hub approach that you showed right now, you can definitely use the authentication page. That's part of the Azure static apps too, authenticate your users properly. And I believe they have a dedicated doc how to set that up. But part of that is knowing that you have a lot of routes that's already set up to handshake the authentication bits and everything else and decide permissions towards certain endpoints, for example. Gotcha. So we got through the big need of everything. We even took a look at the service within Azure. You showed us some code examples. He explained a little bit of code for us. And we've got a little bit less than eight minutes left. And I was curious if there's anything else you think is worth mentioning before we start wrapping up. I think it's important to mention that there are these three different options.  I haven't heard about Azure signal are. I've definitely added real time capabilities some five, 10 years ago when signal are still existed. I think it's good to know that as a C sharpen dot net developer, these two options exist for you. So you can either use a function app with C sharp that works perfectly fine or you use that approach that you showed in the sample docs where you're using the hub. And that works too. But what you need to know is that the hub solution is using a version that you need to deploy your dot net app on an app service. Whereas the other one is an Azure function app to that you are deploying. Both those are viable options. But for everyone else who's not a developer, you don't have the full smorgasbord, right? You have the Python, you got JavaScript.  So under the hood, under those SDKs, there is a REST API where you can connect, you can send messages, you can send echo signals, you can do a lot of things. So that docs page that shows you those tutorials is a really good one, right? Because it shows you those different approaches. Yeah, and we've got lots and lots...  I just wanted to show everybody there is some great docs here, the SignalR Getting Started page, the introduction to SignalR, and then the Azure SignalR Service documentation, which gives you all the bits and pieces that we kind of took a look at real quick. Yeah, and also, I think it's kind of good to keep in mind how that billing model works, because I don't want to come in here and say, this is great, and then you end up getting this huge bill, right? So there's a billing chapter in there when you can see, but hopefully, by today's talk and discussion, you know more about, oh, outbound messages. I understand when I'm being billed, and I understand that I'm being billed, and it matters the size of the message. So if I suddenly get this huge bill, there's a reason, maybe you're sending millions of messages, and if you are, and you have a chat app, there's definitely some wild true code somewhere, right? So it kind of, yeah, go ahead then. Oh, it's gonna say, and they're going along the way of talking about documentation. There's a GitHub project with a bunch of samples that I think people can take a look at under the ASP net. So some of the things that Chris has done today, you can do it on your own. There's the advanced chat room, chat room, so you can take a look at the Azure signal, or all our samples repo within the ASP net, and start building on your own if you'd like to. Chris, I got a question for you before you kind of finish up. One of our viewers wanted to know if you have a copy of this deck so that they could take a look at it on their own. Yeah, 100%. I can definitely send that across to you, and we can get it out there. One thing I wanted to say to wrap things up is that can we go back to that SDK sample, because I'm thinking that's on GitHub? Oh, yeah, sure. So what's good to know, because one person in our audience there asked about authentication. Now, one of these samples actually have authentication built in. I can't remember if it's the chat room local or chat room. It's one of them. So if you look at the pieces there, it's dealing with authentication using Azure Static Apps, if I remember correctly. So this looks like .NET. That wasn't the one. I think it had JavaScript on the back end. So one of these is a very simple, it doesn't use any authentication, and the other one is. So if you want to have this head start, knowing how to authenticate, that's also .NET, right? Yeah. So here we are. Here's some more .NET. Looks like they're all .NET in here. Yeah. So if you go from the official docs page, I believe it's leading you into here. But so one of the examples, definitely I can provide that link after this, is using authentication. It's using Azure Static Apps. So that's kind of good to know, to understand at what point am I being authenticated? How do I ensure that the right person is talking to the other right person? For example, if you have the right sharing app, you don't want the wrong driver to be talking to you, right? Absolutely. So we're just about at the end, Chris. And I wanted to make sure you had an opportunity. Do you have any other events or things that you're going to be doing or new pieces of work that you're looking forward to sharing for audience so they know? Yeah, that's a fantastic question, Jay. Thanks for that. We have a lot of repos that we have been creating as part of our academic team. We have a lot of four beginners repos. So for example, web development for beginners. We have 24 lessons, machine learning for beginners, and so on. One thing that, so that's what's already exist. Now, what's in the pipe that I'm really excited about is the fact that we are about to create a lot of workshops right now as part of our team. And I'm hoping to share that soon. So that will definitely come as part of a workshop repo. So that's up and coming probably in a month. Let me also provide you with a link to a lot of these .NET workshops because I believe one of them is using SignalR, both the old version and the Azure Static apps once. So they have a good sample and a good starting point. But hopefully everyone today that you feel like, yeah, okay, I kind of get it how it works. I got two clients, I got a backend, that backend is talking to Azure and so on. So hopefully y'all don't feel intimidated by trying to add some real-time capabilities because that can really make a world of difference of how responsive your app seems. Well, I'll be getting those links from Chris. We'll put them in the show notes. It'll be on the dev.tubelog post that comes up shortly after so that you're able to kind of take a look at these code samples, these different ways of implementing these things that the educational team or academic team rather want you to take a look at. So Chris, we're right at the end of it and I just wanted to say to you, thank you so much. I really appreciate you being part of the show today. I learned a little bit more about SignalR. I went through some of the learn module yesterday and kind of just tried to grok as much of it as I could just so I felt like I could ask some smart questions of you. That's really it, Chris. I know it's a little late in the evening for you so I really appreciate you taking some time out of your evening before you settle in for a nice relaxing end of your day. And I just wanted to say thanks so much, Chris. Thank you, Banshee. I'm super happy to be here for the second time to see all your series, how it plays out. So yeah, super happy to be here and I hope everyone who listened in today that you felt like I'm actually being inspired or maybe you even got some questions answered. So great to be here. Thanks a bunch, Jay, and thanks everyone for listening. All right, everybody. Until then, let's give them the big wave. Goodbye. We'll see you next time. We've got another great show coming up next week. Always appreciate all you take and pardon it. We'll see you then.


card number seven. Ruby kills Oswald. So many assassinations in 1960s. Ruby kills Oswald. And this is Ruby Oswald. This is a famous video. The other assassination, right? One of the other assassinations. And this is, check this out. This picture right here is when they were bringing out Oswald. And the hand here is Jack Ruby coming up and shooting Oswald in the stomach, right? And the police officers that were holding Oswald, they basically let it happen, right? They offered Oswald as a sacrificial lamb. And there's a lot of shenanigans with this as well. Beautiful picture. Beautiful picture. Beautiful painting. Right? To focus on this. There we go. Look at that. Absolutely beautiful. I think he fired twice. Ruby kills Oswald. On Sunday morning, November 24th, millions of television viewers watched in shock as Lee Oswald was shot dead in the basement of the Dallas police headquarters. With Oswald gone, the evidence against him escalated. On the 25th, Dallas police revealed they had found Oswald's palm print on his rifle. The funeral director later said police officers had spent hours with Oswald's corpse, leaving ink all over his hand. Oswald's killer was Jacob Leon Rubenstein aka Jack Ruby, owner of a local strict joint called the carousel. Ruby's perfectly timed, unseen access to the basement suggests the complicity of one or more Dallas policemen, many of whom frequented the carousel, where they received free drinks and occasional favors from Ruby's girls. Dallas police chief Jesse Curry chose the basement route for Oswald's transfer to Dallas County jail despite early morning, morning phone calls warning of a plot to kill Oswald quote right there in the basement and quote to kill Oswald right there in the basement. The officer in charge of basement security was Lieutenant George Butler, whom Ruby had known since 1947. Like many Dallas police, Butler was a KKK man and he he moonlit moonlit it as a personal security guard for oil billionaire H L Hunt. Moments before the shooting, Ruby concealed himself behind his friend of 11 years, Detective William Blackie Johnson. In 1963, Ruby's failing nightclub was for sale and he owed $40,000 in back taxes. Three hours after Kenny's assassination, he went to his bank with $7,000 in large bills. He then closed his club and for two days he stalked Oswald, visiting the police station several times before finally silencing him. He had had someone made Ruby an offer he couldn't refuse.


I can't show you any more funny videos. I'm a hacker. I work at Big Man and stuff. I'm going to check in the blog code. I'm going to check out. Yes? Yes? All right. Cool. I work in physiology traditionally, but now I'm into computing. I started this software named MGMT. I can't show you much in five minutes. I'm going to show you two demos. So the first thing is kind of like puppet or ansible in that sense, but the resources are reactive. And so I'm going to run MGMT on the left over here. And I'm just going to ask it to create one file. And you can see I'm just catting in a loop the file so you can see what's happening. And the cool thing is if you actually delete this file, it comes right back as every resource, whether it's a virtual machine or a package or an EC2 instance, it's always playing within real time. So you can remove it, comes right back, remove it, and even cat it right after. MGMT is so fast it will fix it before bash gets to it. Cool? And just to really rub it in, if you watch dash n 0.1, this whole command, you can see that it's really going very fast and like really killing it. So there's more in this. There's demos you can see if you want to see how it actually works. I think this is what I think is config management. But the truth is this is what I really think is monitoring. This is how monitoring should be. You set up all your infrastructure. You describe it. And the monitoring is sort of built in per resource, per thing that you're managing. Make sense? In like five years you're all going to be doing this. You're going to remember this talk. Second demo. To describe what I want everything to do, I don't want to blast a big YAML file because the YAML file implies there's only a sum number of switches. And if you want to do something different, you have to ask the YAML programmers to make you a switch. So we have a reactive language. This is the code I'm going to show you. This language and the data flows through like streams. I'm just going to run it. And basically the language will automatically reevaluate what's necessary. And if I actually just show you, I've asked you to just print out a text file which has a whole bunch of stuff in it. And you can see that in real time it's changing. And just to take random input sources, this last one here, this is the load from the computer. It's coming through, running through this code. I have a VU meter. So if you make a lot of noise, it actually is listening to my microphone and taking that as an input source. And any other input source you want, you can integrate into your live infrastructure management. So the joke I kind of make is if you have this in your server room and like your devs are fighting, you could automatically hear the noise and switch to read-only infrastructure for an hour until everything settles down. So that's the sort of thing. So those are really the only two demos I have for you. I'm going to show you a little bit more of what's coming. Oh, hey. Just a little tweak in the microphone. A little tweaking. So there's a whole bunch of stuff left to do in the project. It's just basically on the borderline of being usable. So people who are interested in being early adopters and playing with this and finding issues and adding new resources, stuff like that. How can you help? You can use this, test it, patch it, share, document, star, tweet it, hack on it with GitHub. Hack on it and send me patches. I'm just basically working on my own salary of no money just to work on this. I had a cool job at a tech company before, but I wanted to work on this. I wanted to keep it open source and free software. So if you want to be sexy, funding a hacker, very sexy. You can send me money. You can send me patches. Let's just recap. This is a bad recapping joke. Arthur Benjamin putting the cap back on his pen. We have an IRC channel, MGMT config, Twitter mailing list with some announcements and stuff like that.  I somehow got like five other talks of FOSTA this year because I submitted everywhere that I thought was interesting and they all accepted. So there's five other recordings. Statistically speaking, one of the recordings will probably work. So I'll check out another talk. All of these were available. I'm going right now, rudely leaving this track to go to config management camp in Ghent to give more talks. They're going to be really hardcore and longer and very fun. And if you are around in Ghent on February 6th, which is just a few days from now, there's going to be a hackathon. We're going to do all MGMT stuff. Get your hands on. Play with it. That's really it. If you like this talk when you leave, please go up to the organizers who didn't give me a full talk in this room and bug them and say, hey, that guy was pretty cool. We should have given him a full talk. Is that a good deal? All right. So if you really like it, on the feedback in the schedule, if you go to the schedule FOSTA pages, submit feedback button with this beautiful red arrow that I drew. And if you really want, if you run up, I can give you a sticker because I've got cool stickers, but maybe there's no time for stickers. How much time do I have left? One minute. One minute. Any questions in one minute? Yes, gentlemen in the front. Sticker.  You want a sticker? If you're going to use them, they're crazy expensive, so I got one minute for questions or stickers. Two demos in under five minutes. That's pretty good, right? Let's hear some clapping. Thank you.  If you really want a sticker, run up, and I'll give you one in the corner. Thank you so much.


Call the meeting to order at 7 o'clock. My agenda is on me. We don't have any warrants to sign that I'm a lawyer. Nobody told me that there is any. That sounds good. Makes sense, because this is a special meeting. A special meeting of the select board. We have a very short agenda. The first item is the minutes of February 27th, which was continued to March 2nd. And I have some minor edits that I made. I brought copies for everybody, actually. They had time to print things today. Did you review that motion? What motion? The one that John made, and then I got rescinded. And I wanted to make sure I got it right. I had it in red. I should rescind the approval. Well, let me get to that. Let me go through the mic. That's right. You think the motion is correct? That's exactly the same. All right, so then the other. I'm sure if I got it right. How you got it? The edits that I. Do you have copies for everybody? Yeah. The minor. But the draft minutes reflected $60,394.64, the ARCA funds. And that's the correct number. But it isn't what I was getting when I was doing math on the fly that night. So I don't want to have that in 30 minutes. Because it's inconsistent with the conversation that night. So. So just take that out? Yes, just over committed period. And then the next point, I think, is it's important to clarify the question that was asked. And I, Sharon, would fan and clarify that the board had over promised, but not over spent. Accenture funds already distributed to Fiverr and spent on CB Fiverr and spent on speed signs spent. The funds are still available. So those are the two minor changes that I had. Was there anything else? That's it. That's those are the. OK, so the ones in the folder, are they correct now? So I can send them to Janie to post. Yes, although they look like this. They have traction in there. OK, so I should fix that before I send them. Yes, and the thing that's in red. OK, so we need. So I think we need a motion to approve minutes from the 27th with minor edits as discussed. So March 2nd. And continue to March 2nd. Correct, thank you. So I move approval of the minutes for February 27th. Continue to March 2nd with the minor amendments. Minor. The minor corrections made by the chair. OK. Second. All right. All in favor, please say aye. Aye. OK. Second, we talked in our last meeting about doing a resolution. There was one that we developed and then posted. I gave it to you. Yes, and then one minor, one suggestion from Stephanie who saw the posted version. So this is different than what was posted in the main public. Is the in the second or third or fourth which begins whereas the Calis Conservation Commission. I'll read the whole thing. Discuss the curb cut ordinance and six duly worn meetings between August 2022 and February 2023. And I went back and looked at every single. There were more meetings where it was mentioned, but most of them said several of them said that Stephanie was going to check with the lawyer. So I six is actually substantive discussion at the Conservation Commission. And then this is the addition. And the Calis Select Board noticed the Conservation Commission's work informally several times in the past year. Noted. Noted their work. So when we would raise up, we would go through and I would say they're working on it. Then discuss proposed revisions as a warrant topic on January 23, February 13, and February 27. All three of those meetings, we had that Conservation Commission or the curb or cut ordinance noticed and warned as a topic and to discuss it substantively. And it's in the minutes. And it's in the minutes. And so that, I didn't put this in, but the upshot is there were nine substantive meetings, which apparently is not enough. Apparently not. So anyway, with those changes. Yes. So I make a motion that we approve the resolution as noted with the addition of the amount of meetings that the Select Board held in addition to the Conservation Commission. I don't see where you're going. All right. So is there any form of a non-fantastic or any other actual discussion? Dan, you would like to move on. Sure. So first, I'm going to say thank you guys for your last. Dan Singleton, just want to say thank you for coming out for your last night at work. Thank you for your service. I'll try not to make too much of an issue of a problem. And also apologize for not being involved sooner. Just busy. And so I did have a couple of comments based on, I think, the most current revisions. You're talking about the resolution, because that's the only thing we're talking about. Or the draft. You're talking about the draft. Yeah, the draft. That's great, Dan. But all we're passing tonight is a resolution saying that we encourage the Select Board in the next term to take it up. I was assuming that you were. No, we're not at it. We're not at it. Yeah, it's not creditable. It's not creditable. We're noting that it's 90% done. A lot of excellent work was done. So I'll just for your benefit. And if you can read this generally with the edits we've made tonight on the website, I think Jamie attached it to the calendar for tonight's meeting. The Town of Calis Select Board. So there is a series of where as we kind of walk through the history. And then we say, now, therefore, the Town of Calis Select Board expresses its belief that the current ordinance in its proposed form is 90% complete and is in enormous improvement over the 2004 version. We urge immediate focus and passage in the upcoming 23, 24 term of the Calis Select Board. That's our passage. So what you should do is, I mean, if they take it up and we're urging them to take it up, there will be opportunity for you to hear it. OK. Yeah. I mean, testify. You should do that. OK. Hey, John. Here is the time. Good afternoon.  Thanks for coming. Thanks, Dan. Thank you. All in favor, please say aye. John, we're voting on the resolution. All in favor, please say aye. Aye. Amen. And please approve. We don't have a round robin on tonight, but I'm just going to jump in while John settles in. Hey, guys, let's keep ourselves going. I'm from somebody who might be on the new select board asking us to put in the record a spreadsheet of ARPA funds allocation, which I have here. And you guys have all seen. And I just want to say that out loud. The minutes that we're submitting and attaching, I don't know, I guess. No, let's just say that we'll forward it to the newly elected members of the board after tomorrow's session. How's that sound? I think that's better than seeing the record, right? That's the point. This is we're saying that we're forwarding it to them. We're saying that there is a spreadsheet. As people have asked for it, I've shared it. We're just saying that out loud. Did you prepare this? Well, I worked with Denise's base in yesterday. Thank you for the view for that. OK, so we're just saying that we're forwarding it to them. We're just saying that out loud. But there is a spreadsheet. The actual town meetings. Right, the actual number that is overallocated was 16,39464. All right, so that said out loud, then for the record. And now we are on to a road report, right? Well, right now we've got the guys who ran early folks, obviously, on keeping the roads clear. And two trucks went down, but they're repaired. Right now we've got a spinner that just went out there. They were repairing that today. It's probably already fixing this. This is the spinner. Oh, I'm sorry, it's for sand. They had changed the change, but I think they had some big bind up, and it probably didn't knock either a shear pin or a keyway cut loose. So Peter was working on that today, so that should be up and running. But everything's going pretty well. I hope them actually show up these steps today. They cleared out the school and these parking lots now. I mean, they pushed back a lot of the snow to improve the parking availability for town meeting. So yeah, we're looking. They were, they're actually going to be off tomorrow. The weather's looking good, and they need a break. They've been plowing off for several days straight. Yeah, Peter said they're going to take the day off. Yeah, unless something changes dramatically. Is there anything in particular that needs to be noted for the record? No, there's nothing. There's some transition. Yeah, I think I'll write what you do. OK. The incident that happened on Thursday? All of the forms have been filled out online. Can you say what the incident is? Oh, the truck incident on Valentine Road with the truck. One of the crew was driving and a resident, it was at that narrow bend where there's no, it's narrow. Anyways. It's not there to bend. It was down at the bottom, I was 14 in that. Right, yeah, I can't explain. It's the first time I'm from 14, you know, we talked about it. Yeah, before. And it's constrained by the hillsides on both sides.  Oh, sorry. Yeah. The wing plow was in the back. And it's too many. OK, so let's just let, do these give a question. I've got pictures from the road crew member, pictures from the resident. The forms have been filed online. The estimate for the repairs to the resident's vehicle have been submitted. And I have a statement from the road crew driver that I submitted and one from the resident. And she said she's all set. That VLCT passive. OK. I think it's important for the record for folks to understand and not misunderstand that that road is narrow there, not as a result of any road policy. Right. But due to the topography, it literally was probably a hill that went straight across and it was carved into its sand and it was carved into the hillside or it's literally bifurcating the hill. And it's, the banks and bank vents are steep on both sides and in order to widen that road, I think the town will probably have to buy private property both sides and cut into that so they can shape the banks back. It is not the result of road's policy or any policy or the ordinance. Or the road's ordinance. Road and bridge standards. Road and bridge standards. And it's not been purposefully narrowed. In fact, when Alfred was here and Toby were here, it was an attempt to widen it as much as they can could but they also ditched it both sides, which made it incredible. We had a conversation about that before. So that's for a future select board to deal with. So there's no room to make There's no ability to widen it save for major reconstruction and then likely purchase a private property beyond existing mark right away. Okay, because I want to make sure I put that in the minutes. Anything else you want to add on that? Yeah, this is pretty quiet. I think we're ready then. We're on to, is there a motion to go into executive session under one VSA 313 a three relating to employment of a public office or employee. Second. Yep, moved and seconded. Alright, so we're going to head into executive. Yeah, we're all headed.


Good morning OpenStack. Ladies and gentlemen, please welcome Mark Collier. Once again, Soul Track Mind, our amazing house band. Give it up. Another local Austin favorite. Speaking of Austin, it's amazing for me as someone who lives here to be able to for once not travel to the summit and have you all come here. And one of the most amazing stats every summit is just how far away people travel from. And we have people from over 60 countries here. So it's really awesome for me to be able to welcome you to my city and hope you're all enjoying it. I've seen a few people worried about how many steps they're getting in. Just keep in mind we will be feeding you barbecue later. So we're going to keep it balanced out. And speaking of all the people traveling from all over the world, we have a lot of people here from China. And one piece of breaking news we had this week is that a couple of innovative startups from China, United Stack and Easy Stack are the newest gold members of our foundation. So we're really excited that they're joining the foundation this week. Huge opportunity in China and they're helping us get there. So I want to talk about infrastructure. Hopefully you're interested in infrastructure. If not, you may be in the wrong conference. But I believe I think there's a lot of demand that's just growing very rapidly for infrastructure. So first I just want to talk about a few of the reasons for that. I think everybody knows that connected devices are growing. But if you think about some of these estimates, Cisco actually estimated 50 billion devices all over the world will be connected by 2020. So just four years from now. So what's driving that? Obviously connected cars are growing very rapidly. We heard from Volkswagen yesterday, you know, roads and cities. We're actually going to be seeing a demo in a little while about some of the connected city and smart city work that's going on all over the world. And of course, medical devices, increasingly changing the landscape for the medical profession. But what do these all have in common? You know, our lives are changing rapidly, but we still need to process store and move data. So the basic fundamental infrastructure needs are the same. They're just growing very rapidly. And how rapidly? Well, Mark Thiel, who's an analyst that it's looked at a lot of data center information and forecasted thinks that these new connected devices are going to require 400 million new servers by 2020. And so that's a lot of servers. If I think I see a couple of Dell and HP reps, you know, just hoping this comes true. But the fact is that the real challenge to take this on is to think about how to manage that. There's no way you can possibly manage hundreds of millions of new servers the way they've been managed before. And so, you know, we know when we talk to users and we think about the patterns that are emerging to manage servers at scale to power all these new applications. What people want is something that's programmable that gives them access to bare metal virtual machines and containers. We've been hearing that, you know, all week. We heard it at the last summit. And we'll be hearing from a lot of users today that are doing just that. And you know, I think what we believe the role OpenStack can play is as this integration engine. So when we think about the tools and technologies that are going to happen and emerge to manage that massive scale, of course, it's going to be a huge opportunity for OpenStack. And I think we're all excited about that.  There's no way that just with one piece of software, we're going to be able to solve all these problems and manage scale at that level. You know, we have to look back at some of the past history in terms of how open source projects have come together and created a huge opportunity that's bigger than the other individual projects on their own. So I think of the LAMP stack. Many of you are probably familiar with this. So this is Linux, Apache, MySQL and PHP. So this was the combination where the whole was greater than the sum of the parts. It gave birth to all kinds of web companies, including Facebook and WordPress and Drupal and all kinds of other frameworks and companies. And what was really powerful was that even though these were separate open source projects, users are the ones that identified that if we put these together, even though they're developed in different communities, we can do something really, really powerful. And then because there was clear separation in the stack, you could replace Apache in Gen X or MySQL with Postgres, et cetera. So the real question that this begs is what will be the LAMP stack of cloud? Does anybody know? Because I haven't figured it out yet. I don't think we know just yet exactly what it is. But we're at the point now where we can talk to users and really ask them what they're doing and start to identify the pattern. So we're in this pattern recognition phase, so I need all of you to help me as we look at the users throughout today in the next few days at the summit and beyond to think about what are they doing with OpenStack, but what are the other pieces? Because we have a huge opportunity to identify those patterns, make sure we work really well with other open source projects, and be a part of that 400 million servers that we're going to need to manage in just a few years. So one of the places we look for data to get patterns identified is our user survey. So we do our user survey twice a year. Hopefully many of you take it. I'm sure a lot of you read the results. But in the recent user survey, we asked what technologies OpenStack users wanted to see tightly integrated with OpenStack, working really well in a fuller sense in terms of in their data center to manage it. So containers, no surprise, number one, 70% of people said containers were the most important thing. NFV and SDN, we've heard from a lot of different companies about neutron and networking and what's happening in telco, but also in the big enterprise to network automate, and then bare metal. So we know that that's what our users are looking for, but what are they actually running? So this data speaks to the container piece of it, really more broadly application and management. So things like Kubernetes, Cloud Foundry, I'm sure you all have heard of these, masos, Docker swarm, Cloudify, OpenShift. There's a lot of different choices out there, but people are really starting to dig in and see what meets their needs. And so one of the things that you may look for is which one's at the top. Well, obviously Kubernetes, this by the way is for the past 12 months, so this covers the last two surveys together. It's certainly got a lot of momentum, but I think much like the Republican primary, nobody seems to have over 50%. So the reality here is much like what Jonathan said yesterday, data center diversity. People want a lot of different options. The other thing is interesting, if you add all these up, it actually is more than 100%. Does anybody know why? Because people are running more than one, right? They may be on one OpenStack cloud, but some of their users want Kubernetes, some of them want Cloudify, etc. So that's the reality. And when we think about working with these other communities, people start to wonder, how are we going to get along? How do we make decisions? These are different groups. And I think the same way that the users drove the LAMP stack to become something that was really more valuable than any one project, we have to listen to our users. And at the end of the day, they just want something that solves a problem. And if they can combine OpenStack with two or three other things or more and create value, that's what they're going to do. So when we think about collaboration and our users and listening to them, I thought it would be interesting to just highlight a handful of users and think about what they're doing right now. So we have, of course, users all over the world, large and small. These are not the small ones, though. These are actually the giants of industry. So China Mobile, in fact, each one of these companies is the largest company in their sector, in their market. Walmart's the largest company in the world, period, but obviously the largest in retail as well. China Mobile, I think, is really interesting. Does anybody know how many subscribers China Mobile has? This is the largest in the world, so it's a big number, but probably any guesses? Scott, you look like you're trying to guess. Okay. So they have 800 million subscribers on their mobile network. And they're not only running OpenStack, they're contributing to it. They were one of the top contributors in the metaka cycle. And the point of highlighting these is really to think about how massive of a change the biggest companies in the world are going through to embrace open source. I mean, if you think about the power these companies have had historically, you know, they don't take orders from anyone, right? They're the big dogs of industry. Well, the reality is they're realizing that to survive and thrive in the future, they need to be part of open communities. People from all these companies are here this week. Several of them give keynotes. They're in design summit sessions. You know, like I said, China Mobile, Walmart, we know that a lot of these companies are actively developing and contributing to OpenStack. So they're doing something pretty amazing, and they're really changing their culture. There's a lot of talk about culture yesterday, but I think it's pretty incredible to think about these companies, just these five companies together generate over a trillion dollars in revenue a year and have over five million employees. So to try to move a ship that big is really impressive. And you know, what's really cool from an OpenStack perspective is that these companies running OpenStack, they're serving billions and billions of customers. But you know, why are they doing this? That's the fundamental question. Fundamentally, why are they doing it? And I think what they realized is that something is really at stake for them. If they do not do this, they're going to be in big trouble. Even though we think of them as giant massive companies that they can't fail, there's really no such thing as too big to fail when it comes to the technology industry. You know, these companies recognize that is collaborate or die when it comes to their future. And this is something that I think is kind of amazing to think about companies of that size. But really what I want to leave you with before we start to listen to some users and how they're combining OpenStack with other technologies is how this applies to us. So if these companies can look outside their walls and they can think bigger than their own massive company, and they can engage in open source communities and put together technologies that are bigger than just what they develop in-house, then all of us in the OpenStack community, we should take a lesson from this. We should do the exact same thing. So we should really make sure that we're not just keeping our blinders on, that OpenStack is the only thing that matters. You know, the fact is in that emerging lamp stack, whatever it is, it's going to be OpenStack and a number of other technologies. And this is our opportunity really to collaborate this week and going forward with all these other communities. And what's really exciting to me is that we have people from all those communities here at our summit. So that may be their first summit, if they're coming here from the Kubernetes community or from Cloud Foundry or what have you. So we want to welcome them into our design summit sessions. We want to think about the points of integration, whether it's in the container world, it might be Magnum or Courier or Kola. And we've already had some of those discussions starting this week. And then beyond NFV, we have OPNFV and many other groups. So let's make sure that we're always thinking beyond just what the role OpenStack can play. And we identify that lamp stack for Cloud and make sure we're a big part of this 400 million servers that are coming soon. And so to talk about what one of these users is actually doing, we've got Time Warner Cable. They were a SuperUser finalist in our Vancouver summit. And they're now running OpenStack for quite some time and doing some interesting things beyond OpenStack. So to talk us through it, we've got the Engineering Director of Application Services, Tim Pletcher.


He was back to you from the areas neighbouring the Holy Shrine of Imam Hussein and his brother Abu Al-Fadal Abbas, peace and blessings of Allah be upon them with a services unit but this time we've got a very special story to tell you about the person who directs this very special services unit, the person who directs this unit is a famous person, basically a chef who's famous for his ideas that enlightens a lot of women to cook. Now my dear viewers stay tuned, we'll go to the person who directs this unit and get to know more about the reasons that pushed him to leave aside his restaurant and his YouTube channel and whatever he was doing in his regular days to come here and to provide the services for the pilgrims of Imam Hussein peace and blessings of Allah be upon them so stay tuned my brothers and sisters, basically our brother here as I said the person who directs this services unit is very famous for his shawarma in Iraq we call it gas. So we'll come here, this services unit provides various meals, basically traditional meals, the early morning they cook bagalabaddhin which is a very famous Iraqi meal and at the evening he provides shawarma in addition to kebab. Well let's go to our brother and get to ask him more about the reasons that as I said the reasons that pushed him to be here at this unit to provide the services for the pilgrims of Imam Hussein peace and blessings of Allah, our brother here Naeem who's cooking these various and very delicious meals is here to distribute thousands of meals on a daily basis you see at this very moment they just distributed from the very beginning of this the evening they distributed more than 15,000 meals to 15,000 different pilgrims on the you know in various forms and types of food. So let's get to go to brother Naeem and ask him about you know this very reason because it is the most important thing the reasons that pushes a man to do whatever he is doing. So peace and blessings of Allah, brother Naeem what is the reason that makes you feel that you know your work and you know your work and you come here to provide the services for the pilgrims? I love Hussein and I love the walk of Hussein and the sacrifice of Imam Hussein and the sacrifice of all the people at this moment and our blessings from the blessings of the people of the house. And how do we provide it? And how do we provide it? It is a little bit of their right and that is the reason why we have our homes, we have our work, we love Hussein and we love the visits of Hussein as they see. We serve them and we serve them and thank God that this is a beautiful place, my brother here just said that for the love of Imam Hussein that he came here to provide those services for the pilgrims and since the Holy Imam has you know has given away and sacrificed himself, his family and his companions in the Holy Land of Karbala, he is here to sacrifice the least to the pilgrims of Imam Hussein. Dear viewers as you have seen and witnessed the different stories from the Holy Land of Karbala, from the streets, neighbouring the holy shrines of Imam Hussein and his brother Abu al-Fadr al-Aba starting from our brother who left everything that he does, his business and his business, his family and that you know the other thing that he does and came here to provide the services for the pilgrims of Imam Hussein and the reasons that he mentioned to the other story of the lambs and their symbolism in receiving the Ahl al-Bayt, peace and blessings of Allah be upon them. So that was our tour for tonight, stay tuned for more tours, thank you for joining us tonight very much. Wassalamu alaikum warahmatullahi wabarakatuh.