It's a big pleasure for me to be today here presenting my work. I will be presenting some measures to try to quantify the structure of the brain. We'll start with a very briefly introduction. So as you all know, mapping and characterizing the structural brain network might help to understand how the brain works. In the literature, we can't find many different measures. For instance, we can study integration and segregation with measures like the path length, the characteristic path length, the global efficiency, the clustering coefficient, the transibility, the modularity, and so on. However, still nowadays, compare networks on a study devolution is still a big challenge. And in this world, what we try to do is by using information, the mutual information measure, we try to quantify the structure. How a structure is this brain? But perhaps I should start explaining what we mean when we say a structure.  So there's definitely an organization in this network and there's definitely a structure and this is what we try to measure. I will go very briefly through the main formulas of information theory, the main measures, because this is the base of my work. So it's very important to remind what these measures are calculating. So the entropy, I guess most of you are already familiar with these measures. So it's just the uncertainty of a random variable X that has a probability distribution. Then we have also the joint entropy, which is the uncertainty of a pair of random variables X and Y. We have the conditional entropy, which is the uncertainty of a variable, of a random variable Y given a random variable X. And also, finally, the mutual information, which is the measure that we've been using in this work, which measures the shared information between two random variables. To have a more visual idea of what these measures are calculating, if we have the entropy of one random variable and we have the entropy of another random variable, where there is this overlap of information, this is the mutual information. On the other hand, another thing that we've been using is the idea of a Markov chain. The Markov chain is a stochastic process, which can be described by a transition probability. And in this transition, the probability only depends on the current state and not on the other ones. I will now explain the method by using all of these basic. So we have a brain. We have segmented this brain in a larger scale. And from each region, we have a node. Obviously, these nodes are connected either by using, we can calculate these connections by using DTI or fMRI. And let's imagine we have a particle. This particle starts in a random path in one of these of these regions in the, in the connectome. And this particle visits, according to the probability of the connections, visits one node after node, as you can see in the image, is randomly moving through this graph. From, from this concept, we have generated our model. So we can see that we have the connectivity matrix. In this case, our symmetric. And in this matrix, we mainly have the number of connections that there's from node to node. If we divide the, the number of connections of each node by the total number of connections, we have the probability of the node. And if we divide the, the amount of connections between two nodes by the probability of the node, we have the conditional probability. By using all of these, this theoretic framework, you can now see that we have probabilities of nodes. We have conditional probabilities, which means that we can directly apply the mutual information to, to this matrix. And this is how we understand how we apply this, this mutual information. For us, the mutual information calculates the information that we gain when we know which was the, the previous node. For instance, we will have high values if there is a high correlation between nodes, which means that from one node, I can predict also which can be the connections of the, of the following node. And we will have very low values when this correlation is very low. For instance, in a random graph, it's very difficult to see which ones, or how the, the nodes correlate to each other because the connections are random. So there is no, it is very difficult to predict. So, and the idea here is that the information, the mutual information will be the uncertainty of the state when we have no knowledge, minus the uncertainty when, when the, the pass is known. So this is the global measure. This measure will give a single value for, for each, for each network. And from this measure, we have also used the, to the compositions. And in this case, it's the composition which will give us a single value for each node. We have the, the mutual surprise. The mutual surprise, this measure, this is not new. I haven't invented this name. But it mainly shows how surprising are the connections of, of that node. And it will have high values when the connections are very surprising. It's something that we don't really expect. And we'll have very low values when the connection is, it's connected to, when the node is connected to the, the more likely nodes. And on the other hand, we have the mutual predictability. In this case, we'll have high values when the, the connections of this node reduce the uncertainty of the, of the network. And we'll have low values when the connections of this node increase the uncertainty of, of, of the, of the network. And also if we do the weighted sum of these, these two local measures, at the end, we get the, the mutual information, which is the, the global, the global measure that we've been using as well. Now we show some results. First, we tested our measures with the synthetic networks. We use the Brain Connectivity Toolbox. This is a great toolbox for, for MATLAB. It's very simple to use. And we decided to generate four different types of networks. So first is just random networks. And then the last three are lattice, ring lattice, and a small wall. These, these last three networks, they all have characteristics and properties that we can find also in, in Brain Networks. We generated different data sets with different nodes. For instance, we generated 128 networks with 128 nodes and 156 nodes and increasing the, the number of edges. And also we generate another data set preserving the density. Because the density plays an important role in this, in these measures. So we have a data set with 0.2 density and also with 0.2. And in this data set, what we do is we increase the number of nodes and the number of edges in order to preserve the density. These are the results with the synthetic networks. As you can see, when we have a low number of edges, there is a clear distinction, especially when we have 256 nodes. When the random networks, they have a clear lower number, lower mutual information. And the other three networks, which they have a bit more structure, they, they have a, a larger value. And obviously if we keep increasing the number of edges, because the density of the, the graph on the network, it increase. At the end, all the, all the graph, they tend to have the same value. Because the network, it kind of lose the properties. So at some point, if we keep, if we keep adding net edges and edges in a small world network, at the end we'll have a random network, because there's no small world anymore. And if we present the density, in this case we can see that either for 0.2 or for 0.4, the measures they tend to have quite similar, similar values. And the next results I will show in this case we use human networks. We have a data set with a structural network. This, this information comes from the, the DTI. This was, there were the matrices that were published in a quite a well-known paper. It contains ten subjects, and these ten subjects, we have the networks at different number of partitions. And then we have also another data set. We took from the Human Connector Project. This is a massive data set. It's really nice. They, they give it for free the, the connections and also already the, the connectivity matrices. And in this case we have 461 subjects and also again, different partitions. And what I want to say here is that I didn't generate any DTI. I didn't generate any fMRI. I just took directly the networks that were provided to avoid, to avoid errors. In the case of the, of the structural data set, we can see that the networks are very robust. This was a property that we were looking for. Because what we don't want is that if we receive a new network, we suddenly have a completely different value of mutual information. Because then it would be not useful. So we can see that for different numbers of partitions, we, the values are, are quite stable. But it's not the, the mutual information as we increase the number of regions, it also increased the, the number of, of mutual information. Which means that we have to be really careful when we compare networks with different number of partitions. And then by using the, the functional data set. What we, we could see is that the, the mutual information is, is always very similar. And that's because the density in this network is also very, very similar. And these are the two effects that we could see with, also with the, with the synthetic data set. And now, some examples of the extreme cases that we can find in the structural data set. So in the first image, we can see all the connections. And to visualize this network, I had to reduce, I had to apply a threshold because there were too many connections and it wasn't possible to see the, the network. And for the mutual surprise, the thalamus proper is the, the region that it gave us a lower value. And in this case is because the, the connections are very balanced as well with the probability of the next node. So if the probability of going to the node is very similar to the probability in being in the next node, that's, we can say that that's not surprising. And the other extreme is when we have a very high value, in this case was shown in the transverse temporal. And we could see that the, the connections of these, these nodes were, were very surprising because this node, either the direction you take, the probability of being in that node is, is very, very low. So that was kind of surprising because it has very specific connection, this region. And the last example, these are the results with the mutual predictability. This is the second local measure. We got very low values in the putamen. That's because it's really difficult to, as you can see in this image, it's really difficult to see according to the probabilities of these, of these connections to, to try to guess which is going to be the next node that these, these particle will visit. And on the other hand, this is a very clear example in the temporal we can see that there is a very, very strong connection to a specific node, which is different from, from the other ones. So in this case, we can say that we have a very high capacity of prediction because it's very clear which is going to be or which is the node that will have more probability in this, in this path. Which means that there is also very low uncertainty. And just now to conclude my work, we have seen and I have shown proof of concept that the mutual information can be, can be used to quantify the structure of different model networks. You can see that I have interpreted the connectivity graphs as a stochastic process where particles are modeled as if it were doing a random work. The local measures can characterize new properties of the network nodes that it hasn't been shown before. And obviously we need now a good clinical study. So the data that we've got is not enough to, to draw very strong conclusions. But we have seen very good performance and we have a feeling that these, these measures can be used to, to distinguish perhaps networks with the disease or networks from healthy, healthy subjects. Yes, I would like to thank you for your attention and I'm happy to take questions. If you have a different resolution of the network, you also have a different degree for each individual node. And also you have a different degree within the network. So some hub nodes and normal nodes. To what extent does that influence your measure? So yeah, the measure is, is influenced by the, the density of the, of the network in, in general. I'm not sure how influence is of the degree, for instance. But yeah, it, we have to be really careful when comparing these, these networks. So we always have to take into account the, the density. So as I have shown, we, we want to compare different subjects. We really have to be careful in generating these networks with the same density. So obviously we want to do a good study and see if these measures can be useful. It has to be in the same. Have to be generated in the same way and it's following the same protocols and having the same partition, probably the same nodes and this, this sort of things. So yeah, it's not, it's not that easy that suddenly we are proposing a measure that can be used for any kind of networks and for any kind of, any number of partitions. Okay, thanks.


Over three-quarters of bush and grass fires in Victoria are either deliberately lit or caused by reckless acts. Losing control of a burn-off, operating machinery near grassland or bush or throwing away a cigarette could cause a devastating fire.  You could be charged and fined up to $34,000 and jailed for up to 15 years. For more information, visit the Vic Emergency website. Authorised by the Victorian Government, 1 Treasury Place, Melbourne.


So for the user group to succeed, I have, before we start the talk, because I don't stay in Singapore, I'm going to be looking for people who pick this up and are super interested to take over the user group. So currently Vincent is running it with me as a co-founder, but we're going to be looking at A4 candidates. So if you think that you are interested and passionate about it, please let us know. The second thing is we need speakers. We need people who are working with Kubernetes, so I'm looking at all the guys that have done it before. So honestly, Devin, I don't know if Google want to do anything, but if you're doing anything. So because this is a beginner type thing, it's completely fine to bring something that is maybe not in production, but something that you're trying to figure out and then just come and talk about it, because this is a learning experience about what were the use cases, did you solve it in that particular case, which platform did you run it on and how did you solve it. Okay, so basically if you think you've got a topic, will you please let me know. We need sponsors to host these talks. So if your company is at all interested in hosting it, like HonestBe just did, if you've got a venue and you've got an interest in give back to the community or you're in DevOps, can you also let me know. Speakers, sponsors, talks, anything else like that. You can reach out directly to me on the Meetup page. You can just contact me and let me know if you're interested, if you can contribute. Okay, so that was logistics. It's what I want from the community. Do you guys have any questions before we start? Because basically what I'm going to do is I'm going to go through the cloud native landscape and try and break apart the pieces so that you can understand why I got to Kubernetes at this point and then we'll go through the hands on. So we're all good to go. So who's heard of OpenStack? This is a lot more than I thought. Okay, so 2013, OpenStack was going to solve all our problems. You met me in 2013. This would be an OpenStack user group. It was going to solve all the problems that were out there. So OpenStack didn't solve, but he tried to do what Amazon did at scale, but privately. So if you know what OpenStack is, you're coming from an ops background. So around about the same time 2013 Docker came out, and of course the first time somebody explained it to me I said that it's just a VM because I didn't have enough context to understand that it's actually just some namespaces that the kernel is isolating. And only once I understood what containers were did I realize that the world was about to change. So the people are running VMs today and I'm not knocking VMs. I'm just saying that there's a quicker way of doing things through the containers. So if you go through the evolution of I run my thing in a VM, then I learn about this great thing called a container and it's much quicker to do things. So if you're at that stage where I was running Docker, and it's cool to run Docker on your laptop, but once you want to start running many of them together, you have to start solving the orchestration problem, running them at scale. Okay, it's the evolution. I'm running my app on a VM. I move it into a container and now I want to run lots of it everywhere. So about two years ago, I went out and as a technologist I had to look through the stack and I had to basically go where. I've only got a finite amount of time that I can spend on technology. So where was I going to spend it? And at the time it's mesos, swarm and Kubernetes. The only thing I knew about Kubernetes is that it's a really weird word. So does anybody know the origin of the word Kubernetes? Is it the navigator or the Greek name? It's the Greek name. It's the Greek name for the helmsman. So you can actually now see that. Now once I tell you that it's the helmsman for the ship, you can actually see that the logo is actually the helm of a ship. So you can actually see. So keeping in the nautical theme, what Kubernetes wants to do, if containers and whales are basically shipping containers for code, Kubernetes wants to be the controller of the ship that is steering the containers. So that's what it wants to be. So to break apart the puzzle, the Cloud Native Foundation have got this GitHub page where they've got these diagrams up. And the first problem is if you're new to Cloud Native, there's a lot of stuff going on on this page. There's a lot of players, a lot of projects, a lot of stuff. If you're new to this world, just start at the bottom. It's infrastructure.  The provisioning layer is this interesting, I'm going to call it infrastructure as code, this Ansible Chef part over here in security. The runtime is where Docker made things really popular. So they're at that runtime engine over there on the left. But is everybody aware that Docker is not the only way to run containers? This is an important understanding that Docker made it super sexy and solved a lot of problems, but basically they took a tar file, they figured out how to take a tar file, move it somewhere else, and then run it under the kernel's privileges so it could be isolated. There are other players in town. Don't be completely enamored with just the one technology you'll lock yourself in. There's good things about Docker, there's some negative things about Docker, but there are other players in the space, specifically Rocket from CoreOS. He's another way. Yeah, but I'm talking about the Rocket. Where did they go? Well, there's CoreOS and there's Rocket for the runtime. So let's assume now we've got our containers. So the next thing, as I said, is I had to figure out how I was going to run this thing at scale.  It's all sexy. You've done the nightmare of netting with the port forwarding. And then after that, you want to figure out how to run the containers at scale. So now we're basically at this layer over here. And these are the options for you at this layer. It's a three-way race at this particular point in time. It's between Kub, Swarm and Messos. The others are there, but they're not serious. Okay, this is a personal opinion. You are entitled to another opinion completely. But this is a Kubernetes user group. So the whole reason we're here is because we're talking about the orchestration of containers over here. Okay. Cloud Native Foundation, which now if these are all the players, the Cloud Native Foundation or landscape has adopted these projects from different companies or projects. So these are incubator projects within the Cloud Native Foundation. Okay. Kubernetes was the first that was there. And it was shortly after that followed by HCD, which is a distributed key value store from CoreOS. And it's a key component for keeping state within Kubernetes. So I tend to follow the projects that join the CNCF quite closely because they tend to solve one problem, interesting problem in distributed systems. To quickly call out a couple, LinkAD is an interesting one. GRPC is a protocol for microservices. Rocket is an alternate runtime. To Docker, where's Fluent? Fluent over here is a logging solution, Prometheus. This is a logs solution. Prometheus is a monitoring solution. And there's a couple of other on this. So we're here specifically to learn about Kubernetes, but these other projects they connect in and solve problems in the distributed land space where you're going to be running applications, running in containers. Okay. So the outcome of tonight's session is I can't always be around.  So we're going to build a Kubernetes cluster on digital ocean and long after this talk is finished and on the weekend you're going to come back to it. And I want you to basically to have your own Kubernetes cluster with the microservices application deployed on top of it so that you can pull it apart because the best way to learn is to actually have something running that you can pull apart. And because I've given you the instructions, you can tear it down and rebuild it. So if you break anything, don't worry. Just go back to the beginning, tear down the droplets and start again. When I started with Kubernetes, it was this much time to get the cluster up and this much time working with the application. It was an incredible pain to get a Kubernetes cluster up. It's actually gotten so good now that it's basically about this much time to get the cluster up and I can spend all this time working on the application on this side. So what we're going to do tonight is this front end part where we're going to basically stand up the cluster and get it going. And this is what we're going to do on digital ocean after this. So I sometimes liken coming into one of these new projects as coming into a new country where you need a guide that has to teach you the words that this particular country uses. So Kubernetes has got its own set of words to describe things which you will know as other things. So you may know them as containers. Inside Kubernetes, we call them pods. They're slightly different, but all I'm trying to do is I'm trying to create in the one world we call them this, but inside this particular country and you're all now coming in, you've got visas to enter Kubernetes and I'm going to teach you the terms and words for Kubernetes. To do that, I'm going to tell you a children's story. So this is a website, a link from Deus who in case there were some people here that missed it earlier, Deus was acquired by Microsoft earlier this week, but they do some stunning stuff in the Kubernetes space so it's quite important. And what this illustrated guide, and I'll put this link into the meetup notes and basically you can go through this. If you don't understand the words to describe the primitives inside Kubernetes, come to this website. And what they do here is they basically try to take you through the Kubernetes primitives to make it easy for you to understand what Kube is. You've seen this slide before? It didn't. I don't actually read it. What? Okay. I drew on Microsoft Surface. You asked an earlier question, so I'm going to give you a sticker. I can't remember what it was. You can put that on the Apple logo if you want. Okay, so I'll give you the reason why. Has anyone else got a Surface? Okay. The top gets super, super hot. So when I put stickers on the top, they actually start bubbling. So they actually, it gets too hot. So the stickers basically just slide off. So if you've got a... Let's put the cooling in the top so the stickers that cover our logo slide off. Okay, so no stickers for him. He's giving me a hard time. Nothing for you. So this guy over here told me I'm not supposed to stand up, but I hate sitting down. So you'll notice there's a mic here because I want to go to the white board and use the white board. Oh, you're right. You gave me the definition of Kubernetes, right? So there it is. Sorry? It's in the Wikipedia. Yes, it is. Okay. I'm going to go through this quickly. I'll give you the link and we'll get on to building the cluster. And then I'll be... So I'll be talking about primitives that we use in Kubernetes. Now, Kubernetes is very much an ops-focused tool. People who do ops like Kubernetes because it gives... So who's using Ansible here? Infrastructure as code. One, two. Okay. Infrastructure as code. Basically, Ansible allows you to use these files to describe how you want the application to be defined. Okay, so in code, you say I want it to look like X. Now, this is the first way I'll describe Kubernetes. Kubernetes is infrastructure as code for your containers, for your cloud-native apps. Okay, it is a way of using a manifest file that describes exactly how you want the app to run, but on a cloud-native infrastructure on top of Docker. Okay? So if you're familiar with the whole infrastructure as code Ansible approach to things, think of Kubernetes.  So this first one is it is infrastructure as code for your cloud-native applications. The second thing is it's lifecycle management of your containers. Right? So your businesses, if you're students or your businesses, the secret source for your companies to make money is inside the containers. The developers have gone and written something and it's sitting inside a container. Okay? To make money, that has to be put onto a platform so it can run and make money for the company. Okay? Kubernetes is that platform. It is the lifecycle that wraps that container with, you get it out there, I'm going to expose it as a service. People are going to interact with it and at some point it's going to die. Okay? I'm going to replace it with another container that's got a patch or an updated feature to it. Okay? So infrastructure as code for your cloud-native apps, but also lifecycle management around your containers. Okay? Sorry, I'm going to get up and I'm going to use the whiteboard because I can't do this. Okay? I'm going to quickly do the primitives, the most important primitives for Kubernetes. You've gone and written a container that contains something that you've written and I'm only, so I'm not talking about stateful applications now, I'm talking about stateless, okay? You can launch into a whole discussion about stateful and stateless, but the evening is not long enough and I haven't got that much energy left in me, so we're going just stateless at the moment. So you've written a container and it is a thing of beauty and it makes money for you or your company and you've checked it into a registry. Kubernetes wraps this with primitives to make it manageable. Okay? So this can be whatever it is. The first thing that you've got to know is that it wraps it in this concept of a pod and what a pod basically is, it describes where did I get the container and how do I want to run it? How do I want to run this particular container? Characteristics about how I want to run. So you start to understand the manifest file that describes how I want this to run. So the pod defines how I want to run the container and things inside there like health checks and Vincent helped me out if I skip out other things out there. There's things like health checks. There's things like ports that have to be open for it to run. There's storage that it needs to be attached to. So everything, compute network and storage that you need, like if you remember the VM world, the basics of network computing storage, the pod definition holds the basics for the container. Okay? So the ports that need to be open, the storage that needs to be attached, things where it starts to get different is health checks. So the developer who wrote this knows how to check the health of it. He has to work with a Kubernetes operator that tells him how do I check the health, how do I know that this is alive or not? Because I told you Kubernetes is going to do life cycle management and to do life cycle management I must know if it is healthy or sick and it needs to be replaced. So there are going to be health checks that it needs to know about the container as well. Okay? And that is the pod definition of it. The next thing I need to know about this is how many copies do I need to run? Okay? These are replication controllers. So you can have one copy running or you can have multiple copies running because you may want it to be highly available behind some sort of load balancer. Okay? So the pod definition is which container am I going to run and life cycle around it. The replication control is how many copies I want to run of it. Okay? So I've used words like replication control. I've used words like pod.  A service is a stable vip front end for your container. Okay?  They can live for minutes. They can live for weeks. They can live for months. But they're going to die and they're going to be replaced by the next version. The people interacting with your app don't... If the IP address changes every time this happens and you spin up a new one the people are going to have to redirect to find it. Kubernetes has this concept of a service which basically means it's a stable anchor point. When you come into the app you hit the service. The service will redirect you to the correct container, the correct pod. Okay? This is so important. It's the basis of microservices. Clients who want to use your app only know about the service and this is a stable IP. Okay? Once it's defined it stays there. Right? So any time they want to use it but whether they're talking to version one, version two, version three so now you start to understand how Kubernetes does rolling updates. Right? Because users are hitting the service and they're being redirected. So I'm working on version one. There's a patch. So I decommission one. I spin up two. They still hit the service but they're going to version two of it. Okay? So service is one of those super, super important primitives that Kubernetes gives you. Okay? So we've spoken about pods. We've spoken about replication controls. We've spoken about services. Okay? And that's all that you need to know for the rest of the workshop that we're going to do. One minor addition to that is just that within a pod there can be more than one container. Yeah. So that can be used. It's not used for high availability but you'd be doing with replication controller but it is utilized for support services. So pretty much where Hunter has basically gotten us into is like best practices for pod. Do you run one function within a pod and have it run cleanly? So now we're still talking about microservices, right? Because now we're basically saying that we should do one thing and one thing well. We shouldn't like clutter it with too many, too many functions. So you have to decide for yourselves. Do you want to put more than one? And sometimes it'll be a use case where you want to run more than one container that are somehow related. There can be like a cache lookup and then a web server containers. And you can put them together. So this is a pull and then it does a publish. The only other one that I've seen is if you put the main function and then our friends in Linkerdee, they call this a side card. And the side card does some sort of complimentary function to the main. So Linkerdee basically puts itself in here and basically does a service mesh. So the pods can have more than one exactly as Hunter said but you've got to figure out like which one works for you. I'm currently in the microservices where basically one function, whatever side cards you need to support the main function and let it do it because this means that the guys who look after this, they decouple from the other guys. So now we've got microservices. So I can upgrade this one to whatever version I want without impacting all the other guys around me. And now we've just explained microservices. So loosely coupled but each team can chase whichever function that they're doing. But there are cases where you put more. Can you talk about? Sorry, I didn't know if you covered the fact that there are the unit of scheduling. So if you want to scale, you cannot. I mean, if you put multiple containers within a pod, you cannot scale them individually. A pod is the unit that you scale. So if you have a certain application and you want to scale out that application, I mean, you can only do it if it's at the unit level of a pod. Okay. That's another. Oh, and that also brings me to the other super important. So I said that the replication controller is the number. So this is how Kubernetes does scaling, right?  So that's how it does scaling out. So we forgot the very important aspect of introducing the master that actually runs the control that looks after all of that. And it's only single master at the moment. You can run it as HA? Yeah, but I mean, there is an election that happens when there is one. Yes. What is called like a deployment? Because when I was reading through 180. Yeah, I didn't want to confuse them with that this early on. Okay. Okay. What you've got to get your head around is in the manifest file. So once you figure out all these primitives and you write the manifest file, what happens is I have to get my head around this is they actually they include. So the pod definition is there. Then I think it's the deployment or the replication controller and then the deployment. So as long as you know that they are inside of each one. Oh, and this is YAML. Who loves YAML? Hands up. Okay. Indentation, white space for the win. Okay. The cool thing is, is they coming out with a lint for Kubernetes, that you can take the manifest file, put it in, it'll tell you where your indentation is roughly wrong. These primitives are indented at different spaces within the manifest file. Yeah, let's not go there right now because what I'm trying to do is, I'm trying to keep it really simple so that tomorrow it'll make sense so that when you get to the deepest stuff, you can just start absorbing it. Good question. Is it any one of the primitives makes sense to the number of the containers you want to run? For example, if I have one container, right, I want to run. Yes. It doesn't make sense to run the entire orchestration for a container. I have. I have. Okay. No, no, no. The question, what is the number way it makes sense? No, no, no. There's obviously each, sorry, just one single container. It's just one example. No. Is it makes sense to run the Kubernetes in the two machines? Free. What is the limit within, start making sense really to have orchestration engine? I'm going to answer that in two ways. There is a number of engineers ratio to work, right? And if you, so here is my third way of explaining to what Kubernetes is. The more I worked with it, the more I actually realized it's an operating system for your data center.  But if you think about it, you put Kubernetes onto your systems. Okay. I installed Kubernetes and it's done exactly like this is a master controller. And then all these nodes in your data center become worker nodes as an admin.  This is very much like an operating system today where you work with a single machine and the operating system on here controls the memory, the disk, the networking. And I'm interacting with it and it is figuring out where to go. Think of Kubernetes very much as an operating system for your data centers. Once you install this, it creates a level of abstraction between yourself and the systems that you're going to manage and force basically now force multiplication comes into effect because you have lots of nodes in your data center. Now, when you do Kubernetes and you drop the workload on it and it goes out, you actually won't be SSHing into boxes anymore because you don't care about what's going on in the box underneath. You only care about the app. So it basically is scale. There's a certain scale where Kubernetes becomes relevant to start using. And quite frankly, it's manageable. For me, it makes container. Because it's not infrastructure as code, I get the benefit of knowing that when I move it between clusters and because I've defined it in a manifest file, it's going to look exactly the same between Dev, Test, UAT and Prod. So for me, it's not a when is the size become applicable? It becomes when is my team ready to start? When are they becoming serious about running cloud native apps? When do I have a limited number of engineers, but I've got multiple environments and I want to have the exact same manifest while run between them? So I don't know if that was a good answer, but I'm going to go with that for now. So unless anyone else has got anything else. The question is easy to case scenario. I run right to the service for the entire enterprise where everybody is using the Kubernetes as a service. And I can deploy this in one specific case. So per project, if your project implies 10 containers as microservices for you, maybe it will make sense. But if it's your project requires only three containers to run on three separate machines, is it overhead to running? I can put the same as service as the code in Ansible and deploy a single container. So it's going to be the same as the code. Where is the Kubernetes game in place? Does it make sense to implement the Kubernetes cluster only for free pods? No, I wouldn't say that. Exactly. That's probably something you need to define as a team or as an individual. Because I think everyone has different points where the amount of effort to manage Ansible, or shared for the public or anything else, and that handle payload for everybody else over multiple nodes becomes less work than deploying Kubernetes and getting it running. And in some cases running it on Google Cloud or on Azura where they manage all of the infrastructure for you becomes much easier. There's much less overhead to set up for GKE clusters. On the flip side as well, it may be a smaller environment but it makes sense to run nodes on time and swap them right to the other. So I'll also say that I've hinted at the fact now that because it's manifest file driven and the cluster is running, this means that you can take your manifest file, you can develop it in-house, but then move it to anywhere else that there's a cluster. So who are all the providers who provide these clusters? Google. Azura, Amazon? No. You have to build your own cluster. So basically I'm slamming Amazon, but basically some of the cloud providers offer a Kubernetes API, a native API.  So the native supporters are Azura, believe it or not, IBM Bluemix and Google. On the Amazon sites, like Amazon Summit, Amazon recommends CoreOS tectonic as the official way of running Kubernetes. They actually have this as like, they have a comparison. Okay, but you saw that they recently had another Kubernetes guy join them recently. Yeah. It's not really a Kubernetes guy, it's more a Docker swarm. Okay. That's for a reason. That's for a reason why the HDs are there as a standard in Azure drive format, but there's always a competition just beyond the source technology. There's always a vendor backing. So what tells me that Kubernetes is going to be mainstream is that you've got these main providers that are supporting it as an API, but they're supporting Docker swarm at the same time as well. Google just doesn't do many bad mistakes, apart from that Google Wave and human mashups in 2004. They actually have three significant great things. Yeah. Big table and metrics and whatever. So actually, a number of the, believe it or not, these cloud native projects that make it into CNCF have their origins in Google. So GRPC is stubby inside Google. Kubernetes is Borg slash Amiga. Prometheus, the monitoring was Borg Mon, engineers who went to SoundCloud and then put it out. Carry on. Carry on doing the good stuff. Okay. So we've spoken about the primitives that we wrap your app in to make life cycle management. So this is the infrastructure and that board is in the way. And Kubernetes, and this is what we'll be building in DigitalOcean, is we'll be doing one master and two worker nodes. Okay. So I really explained to you what a service is, right? The service is a stable anchor point that you enter into the containers that are running inside a pod. So exactly as Hunter said, you can have more than one container running in a pod. Microservices approach to programming says that you have one, do it well, and have some side calls with it. This is exactly what we're going to be building. And all that you have to know is that there is a concept of a master and these worker nodes. When you sign up with Google or Azure, you actually are out of the infrastructure game. You actually don't even know about this stuff. There's actually just an API running on the master. And you're just giving the manifest file to the API. And it is handling this for you. The only thing that the cloud providers want to know from you is how many of these nodes do you want? And do you want to do scaling out or not? So if you want to get out of the infrastructure game, if you want to get higher up, you want to get to the point where you're actually just taking your manifest that has your secret source and you're giving it to the operating system controller and it's putting it out. Now some of you will be running this in-house. There's most clients are thinking of running something in-house and then splitting their workloads between other cloud providers. And that's where they're making the choice about is their native API point for us to connect to in this. Okay. So I've spoken a lot now.  We're going to just be doing cut and paste, cut and paste, cut and paste, cut and paste on digital ocean after this. So if you guys want to sleep, that's fine. It's all in the gist that you can follow. So what I'm going to be doing is a lot of this stuff can actually be run at the same time. You can cut and paste these commands, but I've actually separated them out because I want to basically allow everybody time to follow to select the command and then paste it into it. Okay. So those that have got digital ocean accounts and SSH keys ready to load, we're going to do the workshop part of it now. Do we need a short break, stretch legs, air? Do you have free coffee? I don't know about coffee, but soft drinks, sugar, yes. Do we want to do that now and then do the workshop part? I think there was a lot to take in. What do you want to do, like 10 minutes? Yes, should we just take 10 minutes for everybody just to stretch legs, maybe get some caffeine or sugar and then we'll come back and we'll hit it. We can get some coffee, like pre-mix if you want coffee, if you really need coffee. So we'll be back at basically 7.30. Right. I'll get one.


That's probably the most relevant thing Supernatural ever did. Ooh, that's a hot mug, guys. Hey guys, this is my review for Episode 16 of Supernatural Season 7 Out With The Old. Now this episode is absolutely 100% very clearly shot in Fort Langley. This is the second time they have very clearly shot here, with the first episode being the one with the Buffy alumni actors using the town hall. This one, they shoot it right on the the port and then they also go right down into the downtown area where there's coffee shops and stores and whatnot. Funny enough, the whole idea of the Leviathan lady buying all these buildings and whatnot to real estate all part of Dick Roman's big corporate takeover-the-world plan isn't very different to that of what actually happened to Fort Langley. A lot of those businesses that you see in that video are all different. All the buildings are pretty much the same. There was a little bit of reconstruction in the area where they were taking down buildings that were just beyond repair. It definitely has improved quite a bit, but actually let's talk about the episode itself. It's not bad, actually. This is actually one of the few episodes where I enjoy most of it, but at the same time I am still at the stupidity of some of the writing. Just after having given us whiplash for revealing that Sam is full-on seeing Lucifer now and Mark Pelleringo giving a pretty funny chilling performance, he's not in this episode, but he's apparently there. Apparently he's singing Stairway to Heaven 50 times in a row, and Sam can't sleep. So he's driving around in this dingy little truck that's got this U-Haul thing attached to the back and he keeps on almost crashing. And why would you bother doing such a 180 on his progression, his ability to handle Lucifer, to then remove him entirely from the next episode? Not to say that there isn't actually good meat in this episode, funnily enough considering it's about Leviathans, but his absence is so jarring considering what he did and what he established in the last episode as this manifestation of Lucifer.  Their origins is not exactly well known, just that this guy's mom or grandma was like a keeper of a cult thing. Then halfway through the episode turns into a Leviathan one where you find out that the realtor lady in the town is a Leviathan and her pipsqueak little letcher guy is absolutely hating being her lack to the point where he actually helps kill her and because he wants to eat her.  A lot of things are being kind of thrown out in this episode, but the pacing, the humor, the worry that's going on with Sam is still done pretty well for the most part.  I really feel like this episode wanted to be two different things, like no it's not a Leviathan one, but it is a Leviathan episode, but it's not a Leviathan episode, but it's about Sam's issue with seeing Lucifer, but he's not actually seeing Lucifer because we can't afford to get Mark back for this episode, but actually this is really what's happening. And even with that amount of argh, I still was entertained and I actually was quite glued to it. It still has narrative issues, it still has choice problems, but it's still a decently entertaining episode despite its many fallacies. So in the end I'm going to give this episode a four out of seven.  I don't know. This is literally like rewatching the newer seasons. I am very curious at how I'm going to feel going into eight and nine and ten. I'm wondering if I'm going to be a cynical. I'm getting that angry Jeremy who didn't like supernatural fives again, but those are my thoughts. Let's see what you guys had to say. Out of the oldest fun hybrid of rabbit's foot episode that ties really well with the Leviathan plotline while Sam is plagued by its trauma. I love the uniqueness of each cursed object and how it affects the community. The Leviathans are once more flexing their intelligence buying up real estate properties. The twist revealed that the coordinates at the Wisconsin are for Leviathans to find a cure for cancer, still surprising in a good way. Watching Sam increasingly get worse of his trauma is saddening and a real relatability to it.  One is that we don't see a body, which can mean Frank gave up and purposely vanished with everyone from everyone and everything. And two, because once one of the Winchesters are losing their resources to defeat Leviathans making it near impossible. I'll give you credit on the second one. The second idea of Frank's death, I still think it's just, I don't know. It just feels like such a very short pull out. There's no build up to it whatsoever. Out of the Old is an okay episode. My only wish was that Lucifer would return and bug Sam into messing up on the hunt or at least questioning his surroundings. I do enjoy the Leviathans side plot hole and how the boys are able to work together with one of them to take down another. The idea that Sam has been trying to stay awake with coffee is sad, but it means to an end and does continue for the next episode for the whole problem to solve. Honestly, I couldn't have gone with one more episode with seeing Sam seeing Lucifer and Dean trying not to lose his mind and help keep Sam through the hallucinations. I feel really bad for Sam this season on a side note. Sam's arc is the only thing that kept me going through season 7. Yeah, no, it's definitely one of the few things you can latch on to. Out of the Old. I'm not going to pretend this is a good episode or I like it. The episode showcases the biggest problem of the season that is the Leviathans. They're supposed to be these perfect monsters and yet they're not threatening the slightest and they're treated more like a sitcom antagonist rather than a legit villain. Let's not mention the cheesy dialogue. I tried to compare them to the other poorly-received villains that we've seen if they are better. However, I couldn't find any positive quality to them. Even Michael, the British Men in the Letters, they were weak villains, but at least the show tried to make them menacing. I don't understand the direction that Sarah Gamble took with the Leviathans, but it certainly made them the worst villains in the show. Yeah, they're not great. I think it's because they're just so unfocused and just how boring they actually are. All they do is they eat people. I don't know, I feel like it would have been more interesting to see them really kind of build into the politics idea. I like how they're kind of touching on it with a real estate thing, but it's just so obvious, especially considering now, like when you look at it now, it's so obvious. I don't know. That's those are just my thoughts. All right guys, thank you for those comments. The next episode is the born again identity. I imagine this is going to have Lucifer back again. Maybe they could afford Mark for this episode. We'll see. Give me your guys' thoughts about that episode in the comments below and I'll read those off in the next review. Until then guys, I hope you guys are enjoying the reviews. If you did, leave a like and if you're interested in more, subscribe. Until then, see you guys next time.


What's up guys? Here are my quick picks for the final four of March Madness. This time around I'm picking the three best bets for the Kansas and Villanova game. My first bet is Villanova plus four and a half minus 110.  This team just knows how to win. They have met Kansas three times in the tournament and each time the victor has gone on to win the national championship. Kansas in 2008, Nova in 2016 and Nova again in 2018. The Wildcats have been lights out defensively in this tournament. They held Michigan and Houston to just 99 points combined and no team has scored more than 61 points against them in this year's big dance. The Wildcats are a top 20 team in the country in defense efficiency and are allowing only 30.1% shooting from behind the arc. Nova leads the nation in free throws percentage at 82% and are running hot at 90% during this year's tournament. The Wildcats also forced turnovers on almost 19% of defensive possessions. Head coach Jay Wright is one of the best in the game and will be ready to go with the game plan in place after losing a key player in Justin Moore. Nova attacks the glass from all sides and from all positions. Size is never an issue for them as they do a good job for handling bigger teams without issues. My next bet is over 133 points at minus 110. Like I previously mentioned Nova is number one in free throw percentage. If you foul this team you're essentially giving them free points. They have an incredible offense and can make it rain from threes as well. Kansas is also elite offensively and will put up a fight in this matchup. The Jayhawks are ranked seventh in offensive efficiency making nearly 54% of two-point attempts and more than 35% of three-point attempts. They're also strong in ball security and offensive rebounding creating extra opportunities and preventing teams from turning them over. Almost 54% of all of Kansas field goals have come off assists this season so good luck attempting to shut down a singular player in this Jayhawks team. Kansas wants revenge from their last matchup in 2018 where Nova beat them by 16 points so they'll come out guns blazing. My projections have both these teams putting up 70 plus points. And for my last bet I'm taking Colin Gillespie over two and a half three pointers made at plus 120. In the previous round against Houston he went 0 for 4 from deep. However in the rest of the tournament he's averaging 8 attempts from behind the arc per game and if you take out the Houston game he's averaging three three pointers made per game. With just a more out of the game clone will likely take on a larger role and lead the scoring for the Wildcats. He's averaging almost 41% from the range on the season and should keep the hot streak alive in this game. You can find all these odds on the Fandall Sportsbook. Good luck!


We're here with Alicia Greenwald, a nurse practitioner at Healthy Living Health Care in Falmouth. We're going to talk about the summer and what can go on for people to have a better healthier life, feel better physically, and I know that you work with people who live with diabetes, and you have some tips for them and for the rest of us. Well the one thing that a lot of my patients who live with diabetes often forget about is activities in the summer that they don't consider to be exercise, such as mowing their lawn or gardening, or just walking on the beach, and so a lot of times folks that have diabetes take medications like insulin or certain diabetes pills that are designed to lower blood sugar, but when you combine that with exercise, such as the things I just mentioned, sometimes the blood sugar can go too low, and that causes something called hypoglycemia, which is dangerously low blood sugar that can lead to unconsciousness. So some of the things that I recommend my patients to do before they engage in things like mowing their lawn or gardening is to simply check their blood sugar before they do that so they can be sure that their blood sugar isn't too low to start because it's going to go lower, and that's simple to do with a blood sugar meter. And so if they check their blood sugar and the blood sugar is less than 100, that's too low to get started with exercise because it's going to go lower. In fact a blood sugar that goes under 70 is considered hypoglycemic, and that's when a person's going to start to feel pretty awful. And if that blood sugar is under 100, we recommend that that person eat a small snack to raise their blood sugar a little bit to compensate for the fact the exercise is going to lower that. So things like fruit or crackers or milk, things like that can raise your blood sugar enough just to get you by for an hour or so.  Yes, it's a smart idea if you're going to be out for a while to carry little snacks with you in your pocket. Wonderful tips, very simple, common sense, and easy, really just paying attention. Right, just being mindful. Great, thank you so much, Alicia.


What's up everybody Jason for jasky's case race calm 2021 panini immaculate baseball four box half case rate picket He's number 11. Just sold out and again guys here. We go Next half is in the store guys fresh case Here we go This is the wrong list This isn't the right one Well, it's actually the right list. They think but The titles wrong Here we go guys, sorry about that Steve Burch got the hash of last bomb. Oh, Joe One two three for the left four five six for the right One two three. So these are gonna be for number 12. All right. We go guys Tristan of McKinsey 11 out of 49. These are all gonna be 180s jumbo jerseys for Cleveland garden's going to Kevin and a one of one look at that Anthony Rizzo Little patch Is that like majestic authentic patch? Very nice and that is a Chicago Cubs Edition bet you don't have that Jonathan. Congrats, man Add that to your collection. I don't know if you actually still collect resort or not, but I know you're more old school That's still a nice one there And how about shadow box signatures black Aaron judge? I have no idea what signature black is But that is for the Yankees though dusty Let me Pull up the checklist really quick shadow box signatures and Black is number to ten or five So normally Actually, so this is probably gonna be out of five because normally Aaron judge is normal to 25 So there's no way he'll be a red obviously because that's already less than that He won't be a hollow silver that would have been a 10 So black would be out of five because he's a number to 25 if he was not a 99 like Peter Lonzo That most likely would be out of 25 or out of 10 But since he is number to 25 or less already in this set. He's number to five. So black is number to five No, I know what you mean Brandon. This is but this is a little different This is more like a shadow box. So that's number to five. That's a little train whistle for dusty Very nice box so far Jesus Lizardo Ink is kind of fading there. Oh, yeah, you're right. I forgot that was a one-on-one There you go. I just hit my head. It's always out of five or less Here for both of you guys right here So both of you guys right here All aboard the big hit express Adrian Morjo to 25 Jacob and Joey Bart 60 out of 99. That was a pretty nice box All right, Casey mice 10 out of 10 Detroit gonna Tyler. Oh Redemption behind Harold Bain said 20 Garrett crochet rookie triple material memorabilia signatures red So I believe that's another Another white sock. Let's make sure what number in that That was rookie triples and red would be out of 49 Some of the white talk right there Add with that one You've only done a one box Logan This is going into our second box No wonders yet. I know you're also just curious because you're thinking about buying them probably in number 12 But no not to my knowledge At least not yet to 99 Luen Diaz for Miami Adonis Medina 47 out of 49 and Alex Kierloch 3 out of 25. All righty snoozy lose man. I think it's the other there Logan THE Y Apostrophe RE Transgression 11 out of 49 for the Padres the Padres of San Diego Me huntin a San Diego Jacob down Stan the man musical three out of 15 St. Louis Whoa St. Louis is Steve Birch Very nice And close coach worn used material And we have a blockchain of Isaac Paradis and that's a rookie patch autographs button. I Believe Isaac Paradis is a Detroit lion or Detroit lion Detroit Tiger I believe William Contreras for Atlanta Not a jumbo Fielding glove. Wow. It's a fielding glove right there three out of five That is awesome. And that is ATL Atlanta Matt L Kyle enters for Chicago Cubs 75 out of 99 Luis Camposano nice little RPA 50 out of 99 for San Diego Beautiful patch and Walker Bueller 31 out of 49 as last box. Remember the second half is in the store She's I think we might even be We're at 23 already So even better Looks like maybe we're selling out that filler for the baseball mixer 16 left on that one So we should be able to get that done tonight 25 out of 49 will Clark John's gonna make up Joseph. We have Hoyet Will him will home That is for Atlanta 47 out of 99 It should be a lot of braves is if it was Milwaukee that could have been Milwaukee Braves But gets to still would have been to Atlanta. And yes, that is Atlanta Braves Out of 25 Joe Adele for the Angels not out of down two out of 25 Brandon Marquez 33 out of 50 when they're for Chicago Justin Turner for the Dodgers 91 out of 99 very nice signature there And last one here is a hose egg our seed of 49 little RPA three-color pass for Cincinnati When a Nicholas L with the Reds and there we go guys, that was the break So second half is in the store if you guys want to run it back at 23 left Jasper's case breaks.com guys. Appreciate it


Really, you know, make, make your point and excited us and make us, make us want to learn more. We'll even read your paper. So Ricardo, the leg, the Lego to Rome. Are you here. Yes, I am here. Okay, go ahead. Thank you very much for the invitation. Let me just. I think I have a problem with it. Can you, can you see my screen? No, no. No. Now you should always share the desktop itself. It's easy. No, we cannot see your screen. You need to click the share screen button. Yes, in the middle of it should be in the middle of your screen. So screen. Can you see now? No, no. Very disappointing. I'm sorry for this. Well, what, so why don't you take this opportunity just to turn your camera on and tell us what you're doing. Me meantime while you're doing that. Yes. Yes. If this doesn't work, then I can, I can, I don't know why it doesn't work because I can see the screen. So this came back doesn't work. Yeah. Okay. I am working. I am ferreted to the University of Primozka. Can you see me now? Yes. Okay, now I try to speak and share the screen. Okay. I am working on quantum radar with some collaborators in from Hoffman Institute, Germany. And then we're going to run it is basically based on the idea of the protocol of quantum illumination. Quantum illumination is a protocol discovered 2008, basically by Seth Lloyd, and all the people were working on. And the idea is to use instead of usual, a quarter light with a minute user entanglement. The advantage of this is that entanglement provides extra correlations, extra correlations between a, you have two photons that you have states quantum states. You have beams composed of disguised by quantum states, one with two photons, one of the photons, the two photons will have correlations and these correlations, although entanglement is lost in light higher sensitivity. The advantage of this is that the signal to the ratio for quantum correlation is is higher than for any other light of the same characteristics of frequency and intensity. For example, to model the first original model from Lloyd. It's really amazing the enhancement signal to the ratio, one can speak about 60 dv, but the more more realistic scenarios with Gaussian lights scenarios script to back in the states. For them, the theory says that the enhancement on signal to noise ratio is about three dv with respect to current light illumination. So this is the theory and from the theory to the practice is a long path a very different situation. Why, because for to have this enhancement, you need three, do you need three conditions, the first is law or the law. If you need low reflectivity for the target, then you need high bright noise environment, can be artificial, can be natural environment, but very high bright environment. The third one is very low signal signal. So when you have these conditions, which are the fundamental conditions for the theory, then this enhancement happens a. This is for any kind of frequency you can work. So this theory is correct. It's like this for a for optical frequency for microwave frequency for x y frequencies. But the case of optical frequency is, is from my point of view is very interesting, because it's the easier to recognize in experiments. So differences microwave, which is much more difficult to get these conditions, especially for the detection and for the generation of the beans of the states of optics is much easier. You can generate entangled states with spontaneous conversion on the optical. The detectors are there. So there are experiments on the on the optical regime since 2013, which are basically are quantum laders. The sense that they use this quantum enhancement and the lighter assets to instead for for lighters, but they are prototypes. They are experiments in the labs, the distance are small. The integration times are large. So everything is like an embryo state. In this sense, so quantum lighter is a is a is the prototype that use quantum properties of light for my for range detection. And in my work, but what we are doing is to analyze one of the sizes. In which conditions or which applications could have realistic application. This new idea is not so new, but it's difficult to implement. And then seems that optical is good because for what I said before, and the application so one can say could be a enhancement on scanning systems with a with a situation where you need low intensity and you have a bright environment. And to follow it to natural situation for this one is security applications. There is a biomedical applications. If I have to speak of my particular work on this topic, I will say that what they did some quite recently is to generalize the idea from Lloyd. So instead of using a states from with with two internal photons one use states with three photos. Then, basically, when you do this, the enhancement is even bigger is larger. And of course there is a contrast counterpart is that is more difficult to generate free internal photons and two photons, and to detect the triple is much more difficult than the two photons. But this is the situation now so there are also experiments where where it is possible and realistic has been realized to detect free photos. I think Ricardo you're going over time now so. wrap up with a conclusion. Yes, so. Okay, so it's, we got to keep on time. So question anybody have a question, I do. So, let me ask you Ricardo so what. What advantage I didn't quite understand the advantage. So I understand these aren't yet done. You haven't actually implemented a quantum LiDAR. Okay, well, Joe. So maybe Joe's going to ask something a little more relevant, but why don't why don't I let Joe ask a question he's got his hand up. That was actually my question what is what is the primary advantage of using quantum LiDAR instead of. any kind of non quantum LiDAR. So, I think there are advantages. There are, I think there are at least two. The first is enhancement on signal to noise ratio for the same type of frequency and intensity. The second is enhancement on range delay. This has been a different, it's a different enhancement and happens a different domain of signal to noise ratio. But this is the two that I think. Hey, thank you. All right, well thanks, thanks a lot Ricardo.