OK, so thank you very much for having me. So I'm going to be your host today. So let me just bring up the slides and exit this one. OK, so before we start, how many of you have been? So this is session number two. We were lucky enough to do one before this in September. Have you been to the previous one? Raise your hand. One hand here. One at the back. That's it. OK, that's really good. So what we're going to do today, we're going to have a look at this Kubernetes thing. And how does it work? How do we play with it? So that's the goal of today. So most of the time, you will get stuck. So you will need to call myself. And my name is quite complicated. So first thing, let's sort this out. You can call me any of these names. And I will come to you, and I will help you out.  That's the only rule for the workshop. So who am I? I've got a Kubernetes certification. So I think I've got some credentials to teach Kubernetes. And I was lucky enough to speak at KubeCon, which is the Kubernetes conference, twice in Shanghai. And it was a very, very nice experience. But we're not here to talk about me and what I do. No one cares. We're here to talk about Kubernetes and how we're going to use it. So the goal of this session, these three hours workshop that we're going to do, is to learn how we can build applications. So if you are a developer or someone who's interested in just deploying application, first of all, we need to understand what do we need to use? How do we need to change our code? Is anything we need to change when we deploy to Kubernetes? So that's the first thing we're going to do. And the second one is going to be, Kubernetes comes with some rather unusual terms. We don't call things with their names too easy. We don't call Lord Balancer a Lord Balancer. We call it service. We're going to learn how to speak the Kubernetes jargon. And then the third one, I think this is quite ambitious. But the material that we have today goes also into deploying locally and then deploying into the cloud as well, into AWS or Google Cloud. I think it's going to be a little bit ambitious to cover that as well. But the material covers that. And you can practice in deploying into the cloud as well. So what we're going to do today, right? We've got three hours. We start a little bit later. Maybe it's not going to finish at five. We're going to finish a little bit later than that. But the plan is like this. So we're going to build an application, first of all. So we need to deploy something into this cluster. So we're going to build our own application. And then we're going to package it as a container so that Kubernetes doesn't understand applications like Java or Node.js. The only thing it understands is containers. So we're going to have a look at containers. And then I've got part two twice. OK, that's a mistake. This should be part three. But we're going to have a look at how we deploy that into Kubernetes. And we have a look at what kind of things we need to do. Now, there are more parts that we're not going to do today. But you can do it when you go back home. So you can take the material with you and practice when you go back home. And those parts are basically scaling and having state and deploying into the cloud. That's unlikely we're going to be able to cover that today. And then I hope you have time. But if you complete the last challenge, you also get a certificate of completion for today, which I think is quite nice as well. So how does it work? So I don't think you want to listen to me talking all the time. And you want to get your hands dirty. So we're going to have a little bit of me explaining what we're going to do. And then you're going to do it. And it's going to be myself and the rest of the people in the back just helping you out, making sure that you get these applications deployed into Kubernetes. I've got a very ambitious agenda. And we're already late. So we're probably not going to finish at five because we started a little bit later than that. But the plan is to finish in three hours anyway. So Kubernetes is a little bit tricky. So sometimes you might notice that your mini-cube doesn't work or you don't have the right version of Docker or something else. Now we're going to help you out. But sometimes you're going to get stuck. And instead of just being stuck and fixing your problem, it makes sense if you pair with the person next to you. And you just get it through. We're still going to help you fix everything. But I think you should follow the rest of the material as well. We've got Slack. So if one gets usually get lost, they can connect to Slack and they can send me the links and I can fix it. But other than that, I think it's not absolutely necessary. So that is the plan. Before I start, is there any question? How many of you are stuck installing Docker or mini-cube or cube CTL? Raise your hand. I can see, OK, well, we are sorting that out. We are working on it. Anyone else? OK, don't worry if you, yes, I'm going to help you out. Don't worry if this is broken, just raise your hand. We will help you out. So this is the second time we run the workshop. So please be nice. We haven't found the perfect way to teach these Kubernetes in just three hours. We usually run three days workshops. So three hours is a lot less. So we're trying to do our best to make it work. Is there any questions? Are you ready to start? I don't see you excited. Are you ready to start? Oh, there we go. OK, let me grab the slides. OK, so what we're going to do today, we are going to build an application. OK, first of all, we need an application to deploy into Kubernetes. And this application looks like this. It's called Knote. And what it does is a simple, very simple note-taking application. So you can write some content. You can click on Publish, done. It's going to save some notes. We're going to add something else into the mix just to make it a little bit more complicated. And what you can do, you can also add a file. It's going to upload the image. And it's going to insert that image into the text area. Please notice what kind of glibberish is there. This is markdown. I don't know if you're familiar with markdown, but it's just basically plain text with some extra markup. So when we save that and click on Publish, we also get the image as well as the text. So this is a little bit more complicated than just saving text. We're also saving images, which is going to give us the opportunity to explore other areas as well. So the application that we need to build, we have a couple of requirements. So we need an application, something to serve these pages. We need a database. We talked about files. So we need also to store these files somewhere. So if I think about it, then I definitely need something like either Node.js or Java just to serve the application. Then I need a database. I pick Mongo because I don't need to define a schema or anything like that. So it's a little bit easier to get going. And I need to connect those two together. So the plan is to use just static pages. So if you are a React fan, I'm sorry. I'm going to disappoint you today. We're going to upload files and all the rest. So this is a very simple application. So you won't be able to deploy these to production. You have multiple users and so on and so forth. But maybe if you want to go back and refactoring and not whatever you want, that's a good opportunity. So that is the plan. And we're not going to use Postgres because it's going to be more complicated. So we're going to build this application first. I wanted to build it locally. And this is what you're going to do. You're going to create it, connect it to MongoDB, and then test it locally. I want to see you uploading images, you uploading text, and just seeing the application locally. Why? Because first, we build it locally. Then we package it as a container. Then we put it inside Kubernetes. So this is the first step. So the way we do it, I know that you might miss some of the steps. We've got also a GitHub repo. But we've got this URL. So you should sign up to this website, which is called academy.learnkubetages.io. You go inside. There is a page which says sign in. Just enter your email address. Click on sign in. And then you get an email back. Just click on the link, and then you're logged in. So everything we do is going to be from the academy. So you can follow along. And you can click on Start. And then it's the first module. How many of you here are doing the Java version? I can see a couple of hands. Last time, we didn't have anyone. So I'm really glad that even you have people with background in Java. So if you are in Node.js, just click on the Node.js version. Otherwise, click on the Java version. And then the first part is actually describing how to write this application. Now, last time, so what I want you to do is to go and do it. But before you go and do it, I want to show you what the end result should look like. OK, so you're going to clone a repository, right? Either download or clone a repository. What kind of repository you need? So we have two repositories. I'm going to show you the JavaScript version, but the Java version is the same. So we have a learnk.js, k-note.js, or Java. And this repository is what we're going to use today. It's got five different chapters. We're going to do the first three chapters, OK? So you're going to download this, either clone or download it. And then you're going to have it locally, like myself here. So I can say, ooh, it's quite busy. So then we're going to do part one. So you're going to do to CD01. And you're going to install all the packages with MPM installed, or if you're using Java, you do a maven install. You're going to install all the packages. And then I want you to start the application with, let me just, how do I make it? OK, that is not going to work, OK? So what I want you to do is to start the application. So the application is failing, right? Because there is no database. So what you will need to do is to just start the database as well, OK? So once you do that, the application is available. We click on the application, OK? And then it's running. Then I want you to try that it actually works. So is this OK? Yes? You upload it, and then I will do that. Yeah? You can publish it and then check that it actually works. OK, so that's the end goal. Now I'm going to go back to the slides. So this is the plan. You go on this URL, you look at the first page, and then you will find the steps to actually download this and then run your own application, OK? So that is the plan. We have half an hour to do that. So it's going to be very, very quick. And then after that, we're going to start with Docker. So you don't need to complete this part to enjoy the second one. But I think it's still relevant. It's still better if you do, OK? So myself and the others are going to be around and help you out. But the plan is launch the app. Upload an image. Add a note to your note up, OK? So some of you managed to get the application up and running. They had a note and they uploaded a picture of a cat. If you did that, well done to you. If you haven't, don't worry. We're going to try again. But this time, we're going to do it with Docker, OK? So I'm going to start the next part. And we're going to talk about Linux containers and Docker. So I suggest that if you are stuck or someone is helping you, we pause for a second, we do the lecture, then we go back, OK? You can decide to go back and do the previous session or you can do the next one as well. It's up to you, OK? OK, so let's have a look. So generally, you are at work and this is the kind of discussions you have with your colleagues. I built a Node.js app. It's great. And someone comes to you or a Java app. Someone comes to you and say, OK, can I have it? There's a zip file. And so of course you can. Here you go. There's a JavaScript file, some files, some images. I'm going to give it to you as a zip file and done. The person goes off, they run, and it doesn't work. It's rubbish. Why? Because we don't have the right version. It's missing stuff. Had stuffing stored in my laptop, it doesn't work. But it kind of does work, right? Yeah, it does work on my machine. But what about someone else, right? So this kind of problem, they tend to be quite common when you have things like libraries, which are dependent on your operating system. So you might be familiar with a technology called Puppeteer or Fumton.js, which are basically like browsers that you install locally. And then you can do things like Selenium, or you can do a bunch of different things. And then these two kind of binaries, they tend to be compiled for an operating system. So if I have a Windows machine and you have a Mac, how do we share the same file, which doesn't work? So I cannot just simply zip something and give it to you. It's never going to work. And then if you are in a sort of JavaScript community, it's even worse because we've got things like SAS, for example. And not only there are different versions for different operating system, but there are several different versions for also the Node.js that you're using, right? So it might work with version up to 11, and then it fails with 12. And it's very, very annoying. What if we could have something, right? Like the zip we had before, where we just grab everything together and we package it. But this time, all of the dependencies, right? Even the dependencies like SAS or Pappeteer are packaged as part of a zip. So basically, this zip file, this archive is self-sustainable, right? There is no other dependency on operating system or anything else. So we call these sort of packages docker containers, or just containers in general, OK? So docker is the technology that popularizes them, but it's not the only technology that can create containers. So and what are these containers?  And those are what we use to encapsulate our files as well as dependencies to other libraries. So we talked about docker. This is the most popular one, and that's the one you also installed locally to join this workshop, OK? So how does this docker work? So usually, it comes in two parts, OK? So there is a docker CLI, so a command line tool, where you type the commands. But that binary doesn't actually do the work. It's just sending the message to someone else. And that sound else is the docker demon, OK? So when you say, I want to run a container, that message goes to the docker demon. The demon creates the container, OK? So what we're going to do now is we're going to package the application as a docker container, OK? So we're going to write this file called docker file, which is a recipe to create the container and describe what kind of things should go inside, OK? And then we're going to use this other command called docker build. And docker build, well, it does it. We're going to give it a name. So dash t is for name, OK? Actually, it's for tag, but pretend is name, OK? And the other one, this is really important, right? You see here, there is a dot, OK? That means where this docker file is located. And dot means the current directory, OK? If you forget the dot, you will see an error, OK? If you see an error, just raise your hand. We will help you out. So how do we build these docker containers, but how do we run them? So for running docker containers, is we use docker run, OK? And then we've got an extra flag called ti. I usually like to remember these as terminal and interactive. So I can play with the terminal inside a container, OK? And then the name of the image that I want to run. So before we were building docker build dash t up, so I need to put the same name there as well. OK, so we're going to run it. And we're going to see the application running inside a container. So we're going to do exactly what you did before. But this time, we're going to run the application from within a container, OK? So that's what we're going to do. You write the docker file. You run this docker file. And from a recipe, you create an image. Once you have that image locally, you need to run that docker image and run the application again. So the result will be the same, OK? You will see the same application with the same cut. But it will run between the container instead of running locally on your laptop. So again, all of this is in the same material as you saw before, right? So you can just go and click on start. And then depending on which version you've got, and then the part which we are focusing right now is this one, right? The second part, where we build a container. So I want to show you what it looks like and what the end result should be. So if you're following along and you have a repo, then we're looking at version number two, OK? So there's a folder zero two. So I can see what's inside. And I can see that there are basically the same files as before, but there is an extra file called dockerfile. Inside this dockerfile, there is a recipe to build what is basically a zip file, an archive. And what it's basically saying is, from which image I should start, this is like an ISO. If you're familiar with Future Machine, this is basically the base image, the base ISO that I want to start, the base operating system I want to start. And the second line is a little bit cryptic, but it's always saying is, copy all the files that you see locally and put them inside a container. The third line is, install all the dependencies because we need to run this application. And the fourth line is, the default command when this container runs is to run the application. So when I have this, I can just do a docker build, that's T, dot. And this is going to go and execute these steps one by one and build this container. So it's going to take a little bit of time. It's going to download all the dependencies. And eventually it's going to create a container like here. Now with docker, now I've got to build the image so I can run it. So the way I do it, I do a docker run. Now hopefully I've got it, yeah. I've got it prepared in advance because it's a long command. So I do a docker run. And then I start my application. So the application, you can see here, there are a lot of flags. So what are these flags? Let's have a look. So first of all, there is a P flag. The P flag basically means, where should I export this port of my laptop? So I can visit the application. Then there is a dash E for environment. So this is how we pass information inside a container about where is the database located. And the other three lines are sort of a little bit more enigmatic. One is the network. I think I'll ask you to trust me on this. The other two, we remove the container when it's done. And the name of the container is K node. So we run this. I can enter. And my application is broken. Why is it? No, running MongoDB. Well done. How do we do that? How do we run MongoDB? We're going to run it as a container again. So everything you run in this session is going to be as a container. So I can type docker run. Ooh. OK, and this command is actually going to run MongoDB as a container. So before you had MongoDB, you had either to install it or to run an extra command in Node.js to get it running. Now we actually just download it like this. And you can see that it is working. So if I go back, I can see my application now is running, right? Because there is a database where I can save all these notes. So I can click and look host. And I can see the application up and running. It looks the same, but this time it's running inside the docker container. And the good thing is if someone asks me, please can you share the application that even if you're running on Windows and I've got a Mac, we can still see the same application. You won't get a surprise this time. So I want you to do the same. If you're running docker toolbox, you won't be able to get to this application through local host. You will need to have the IP address of your docker machine. I understand that this is cryptic. So when you get to that point, raise your hand and we will help you out. So we're going to have 45 minutes now to try and run the application as a docker container. Any question? All good. So some of you managed to get through the docker containers, so you package the application as a docker container, and you run it, and you saw exactly the same thing as we saw before. We said that the difference is that now you can grab that container and give it to your friend or your colleagues, and they will see exactly the same thing. And that's the benefit of containers. Now, I'm going to go back to the presentation and we're going to discuss how these containers are useful. But when there are too many containers, what do we do? So if you're doing the material, I'm asking you to pause it for a second. We're going to do the lecture and then you can continue. But I think it's important that you listen to the next part. So generally, what we have is we want to deploy applications inside servers or visual machines or Raspberry Pi. I'm not judging. You can do anything you want. But generally, what we do is we provision the environment. So we install the runtimes, we install Java, and then we place the application inside. Now, if you have to do that just for one application, that's OK. But what if your server needs several different binaries, several different applications?  But I don't know if you noticed. With Docker, we just need to do a Docker run. It could be Ruby, it could be Java, it could be Node.js. It's just a Docker run. So in reality, all the application that you build, they look the same. As long as you can do a Docker run, you can deploy them inside your server. And that's the beauty of Docker container. And that's why they are so popular. And many people are using it. So easy to share, so easy to run. So we have our application, and we just wrap that inside a Docker container, and we've wrapped the database inside a Docker container as well, and then we connected those two together. So ideally, I want the same inside a server as well. However, when I run this application scale, I think there are a couple of challenges. I've done Docker run for MongoDB and Docker run for the application, but what if my note-taking application with a cat is extremely popular?  I mean, maybe you can. But what if it's extremely popular, right?  That's a little bit tricky. The other thing that is tricky is that sometimes we have so many Docker images, right? We've got more than one single machine. So we need to go inside that machine and launch a container, exit, go in the other one, launch a container. It's very, very inconvenient. Well, it's inconvenient if you've got three of them. Well, if you've got like 100,000 servers, right? Like Google scale, or even if it's not Google scale, right? You might do like machine learning, and you need like 100 machines. That's a lot of stuff. So is this Docker useful at all? It's rubbish again. What should we do? Well, I think everything was simple when we had a single machine. Everything is simple because everything can be done locally. But it becomes complex when we have more than one machine. Now, again, we can blame Docker for that. But the reality is that this sort of problem is solved by another set of tools called container orchestrators. And there are several of them, and you might have heard of some of them, like Mizzuz, which has been renamed by the way, Nomad, or if you are working with Amazon Web Services, you might have heard of ECS, the Elastic Concerned Service. So those are orchestrator, right? Like Kubernetes, the only thing is that it's not a fair fight. So Kubernetes is by far the most popular container orchestrator. So what is this Kubernetes and how does it work? Oh, do you want to cover Nomad today? Is there a reason why Kubernetes won't open? I think, let me finish the presentation and then I'll address your question, okay? So Kubernetes, so what is and how does it work? So first of all, the reason why Kubernetes is so popular is because what we basically do is we just have a collection of machines and we just install the master node, make the other computer join inside the cluster and they will just behave as a single unit, okay? So that's really powerful. So when we deploy something, we just deploy that something inside a single unit, which is much easy to reason about. The reality is that Kubernetes will take over and then we'll just deploy inside the service, right? But judging where it should go, where these complications should go and how many of them, right? So what we're gonna do today is we're actually gonna try and deploy this application. So in this case, I've got a red page, but the reality is that we're gonna build, we're gonna deploy our own application, our no-kit-taking application inside Kubernetes. So what we're gonna do is, generally we want our users to go to the application. So when we have two instances of it, how we distribute the traffic to the two instances, if you were to do it right now without Kubernetes, what would you use to distribute the load? I would use a load balancer, right? And that's what we do in Kubernetes as well. The other things that sometimes happen is you might have more than one application, right? You might do microservices. So how do we distribute the traffic between the two applications? How do we route the traffic between the two? Any idea? So sort of a gateway, more like a router, right? We need something to distribute this load. If this is for app A, we're gonna send it to the left. If this is for app B, we're gonna send it to the right. So in Kubernetes we have the same, exactly the same component, but in Kubernetes we like everything to have a different name, because we want to feel special, reality, okay? So instead of calling load balancer, we call them services.  And then why stopping there, right? I mean, we can call with different names everything. And this is exactly what we do. We call the application parts, right? That's how it works. So these are the basic components in Kubernetes. So if we've got parts, services, and ingress. But there is another one which, it's not in a picture which is extremely important that this is what are you gonna use right now to deploy your application. And that's called a deployment. So deployment is basically a recipe to create instances of your application, okay? So you say the application looks like this, and then you're gonna say how many copies? The deployment is in charge of creating those copies and then watching over them, okay? So if you want to say, if you say there are five and one is the leases, then Kubernetes will bring that up, okay? So deployment will do the job of just watching over and make sure that they always work. Now, everything you see here is what we're gonna do right now. We're gonna deploy our application, then we're gonna use a deployment and a service to expose it and then just have our application inside the cluster and maybe scale it and see if deleting one part is gonna recreate it. To do that, we need the cluster, okay? So Kubernetes is basically just a container orchestrator. So we need a Kubernetes, so where I go and buy one. And it turns out that you install MeCube and MeCube is a local cluster, okay? And the reason why we find it useful is because it's very easy to start and it's very easy when something goes wrong, you can just delete it and restart it, okay? Generally, we don't have the same sort of luxury when we deploy things in the cloud. So you cannot just simply go and delete the dev server, right, or the dev cluster.  So what we do is we have a local cluster. You're gonna start MeCube, okay? And then we've got something else called kubectl, which is a command line tool, which is gonna send the commands to the cluster. In the same way you have the Docker CLI sending the commands to the daemon, then we have kubectl sending the commands to the cluster. So we're gonna use kubectl to send the deployment and then to create this cluster. So that's how it works. Now, it would be too easy to just send commands. So in Kubernetes, instead of sending commands, we send descriptions of what we want, okay? And these descriptions are done through a language called yaml, which is just a configuration language, right? And we say what we want, how many copies, and then all this sort of configuration. So generally the question I get at this point is do I need to memorize all of this? Yes. No, I'm joking. You don't have to. Okay, this is very complex. I'm not expecting you to remember any of this. I mean, maybe a little bit, just this one maybe, just the image, right? What kind of things I want to deploy. But everything else with time you understand how it works. So don't memorize this, just have a look at it and pay attention to the last line, that's it. The language is called yaml and it's basically just a superset of JSON. So if you want to, we generally don't do this. But if you want to, you can also write the same definition as a JSON payload. It's much harder to write because you need all the quotes and all the curly braces. But if you like hard things, you can do that as well. Okay? So when you send that request, it's gonna get to Kubernetes. Kubernetes will eventually create these resources on your behalf. So now this is exactly what I want you to do in the next session, right? I want you to package the application as a container. I want you to deploy that container inside the cluster and see the same application deployed inside the cluster.  You will also need MongoDB for that and make sure that the application works. Okay? So that's the job. As usual, you find all of the steps in the documentation, okay? So you can just follow along. But I'm planning to show you what it should look like in a second. So as usual, the section we're looking at at the moment is called deploy into Kubernetes, okay? So let me show you what it should look like at the end. Okay, so you're gonna start the cluster with mini-cubes start. So mine is already started, okay? So it's gonna be hopefully. Hopefully it's already started. Maybe it's not.  I thought it was already started. Okay, done. That's the end. So at that point, the cluster is running. How do I know that? I usually type mini-cube status. Okay, it's telling me it's running. Job done. How do I check if it is really running? If I don't believe in a mini-cube status, I type kubectl version. Kubectl version is telling me a lot of things. But one of the things it's saying is the client version and then the server version. So the client version I get always and the server version is the current server I'm connected to. So it is actually working for me. The next step is to go in the right folder and then define what I want to deploy. I do that by defining this YAML file. So this configuration. So the configuration usually comes, you can have multiple files or in like in this case, I can have a single file and then have these sort of free dashes to the limit resources. So the first resource I've got is the service. We talked about the service as just a load balancer. And then the other one is the deployment. So in the deployment we say what the template, which is basically what this resource should look like when we create instances, okay? And then we've got the same sort of configuration variable that we had when we had containers. And then a container port. So I think some of this might be familiar. Some of it won't be quite complicated like this part, for example. So I think for the time being, we don't need to understand this to deploy to Kubernetes. So that's what we'll do. So when you have this description locally, the next step is to just submit that to the cluster. We use the apply command and I'm gonna deploy MongoDB and I'm gonna deploy the application, okay? And that is gonna create the resources. How do I know that? I can do a kubectl get parts. And I can retrieve what kind of application we're deployed. And I can also retrieve the services. So these sort of load balancers. And I can see that both of them are working. So how do I access that? I can do a mini-cube service and then the name of the service and I see the application up and running inside Kubernetes. And I can test it. Oh, okay. I'm not gonna test the images. There we go. All up and running. So I want you to do the same. Start the cluster, write the definition, deploy, show me that it works. We'll be running around just helping you to get stuck. Okay, so I know some of you are deploying to Kubernetes. Some of you managed to deploy to get to the next part, to get the certificate, to pretty much done all of it. If you haven't, don't worry. It takes time and practice, okay? And if you are on Windows, it takes even more time and more practice, okay? So what I wanted to show you today before we close this session. So now I'm just gonna do a quick, I gotta point out the next two sessions that you can do at home to complete the material. So there are basically three things you can do. You can do and scale your deployments, right? And have more instances of the app so you can handle more traffic. And then you can deploy the application inside AWS, right? So the same config file, the same YAML that you wrote today to deploy locally works inside AWS and works inside Azure and works inside Google Cloud, okay? And that's one of the reasons why we like Kubernetes because we can use the same YAML files everywhere, okay? So I wanted to show you what it looks like. So when you go back and you do the material, you have an idea of what it should look like. So the first thing I want to discuss is scaling, right? So this is the kind of scenarios we have now. We have a single pod with a single deployment and the traffic so flows through it. But what you can do, you can use this deployment to create more instances of your app, right? You might say I want to. And then what the service is gonna do, so this load balancer will basically just distribute the traffic from one, you know, to one and the other, right? It's gonna distribute the traffic evenly between the instances. However, is there anything wrong with this design? Is there anything that is not working when I use this application? I assume in that we have MongoDB running, okay? Is there anything wrong? IP address? Close, what about the images? Where are the images stored? I mean the images are in the cut picture and then any other pictures you've used to test it. Yeah? So I can see here an opinion, anyone else in the middle or towards the end? What do you think is gonna happen? Stateful, stateless. See what is inside the pod. See, so if we upload the cut picture, right? Then that cut picture will be stored just on one of the two instances. And that's okay, but when you try to, when the traffic is routed to the other one, when you visit the page and you don't hit the same instance, right? You won't be able to see that image. The application is broken. So we don't want that to happen. So how do we fix this? Put it somewhere else. Put it somewhere else. Make it someone else's problem. I like that. So that's actually what we do. So we call this kind of problem state, we kind of call this problem stateful problems, right? Or just stateful applications. And generally when we deploy something in Kubernetes, we want it to be stateless, right? Why? Because we want to create end copies and not worry about picture of cats or anything else. So what do we do? Well, we have our application in Node.js or Java. We have our MongoDB. And generally what we do is we upload these images into something like a block store. Or like, you know, somewhere where we can put images. If you're familiar with AWS, that's usually S3. If you're an Azure, there is block storage, GCP, not sure what's the name is. But everyone has got their own. Now, there are tools that also mimic AWS S3. So just, you know, a place where you can put these files. So a popular one is called Minio. And Minio is just something that we can deploy it inside a cluster. And it's basically gonna give us an API where we can just call and upload files. Okay? And that's okay because if the files are not on the file system anymore and they are in a central location, then we can have as many instances that we want of our application. And they're all gonna retrieve these images from these sort of other database for files. Okay? So eventually what we want to end up is we've, you know, every time we store a note, that note goes inside MongoDB. Every time we upload an image, image is storing sort of a similar database but just designed to store files, which in this case is called Minio. But it can be any other sort of service that does that. Okay? So that's basically what you're gonna do in the next session. But some of you might have started this, but that's the idea. So you can try and refactor the AMP to make it stateless and then trying to scale it and see how it goes. So that's the next part. And there is another one which you might be tempted to do. Unfortunately, you will need a little bit of AWS credit for the last part, which is basically you deploy into the cloud and then the same YAML file works locally and inside the cloud and you have a fully functioning web application. Okay. So, so what we've done today, so this is the end by the way. I don't have any, we're really over time a little bit but we also started late. So what we've done today is we build the application, right? So if you use Node.js, it was easy. If you had Java, unfortunately, it was almost impossible because we found so many issues. Apologies for that. You package it as a Docker container, okay? So we understood how we create archives and how we can use them to pass them to our colleagues. And then the third thing that we did was to deploy these containers into Kubernetes.  Some of you managed to do all of the remaining parts. Good to you. And I've heard that someone got certificates as well. Very well done. At the end, yeah? I think you should try as well to deploy this application and get your own certificate. I think that's quite rewarding. So I'm going to say to all of you, well done for getting this far. And I think this slide is a little bit broken. I'm not sure why. Yeah. So I just want to say thank you to everybody, everyone who helped, you know, going around and fixing issue and a special thanks to Madhvi as well. So she was, you know, the first session, she managed to do all of it and today she's here helping you out.  But you can do it, okay? And then the next time you're going to be the one, you know, standing here and explaining how these things work. I really do. I think, you know, you should try and we're going to run this session again maybe.  So what's next? Practice makes perfect. So if you haven't finished the material, I think you should, right? It's very useful. And if you have any questions, oh, just ping me. My name is Daniel. You can find me on pretty much everywhere. Twitter, LinkedIn, whatever. I'm not trying to hide. And the material is for you to have. So everything you see, all the PDFs you have today is going to, we're going to keep, it is going to stay free forever, okay? You can use it and we update it. And then the other things we're doing, we're adding more languages as well. So maybe you don't know Java, maybe you know Python, maybe you do .NET. We're going to add those in as well. So this is not going to change. If you're interested in the rest of the content, we offer a discount so you can get it today. It's a little bit of a off, but you don't have to. The other material is going to stay free forever. So we are this company, we basically do training. You can see, we run just running in London. We run one recently in Singapore, which was quite fun. And in general, we just travel around and we do quite a lot of training in all sorts of interesting places. That's what we like to do. So thank you very much for coming. And I hope I'm going to see you again on Thursday. So we are running the Kubernetes Meetup. There are going to be two interesting talks, but I've got a surprise and I'm running actually a quiz night on Thursday. So we're going to ask questions about Kubernetes and there might be prizes. I want to make sure that everyone enjoys, so I'm not going to ask hard questions. I mean, maybe one or two. But if you enjoy that kind of stuff, I hope I see you on Thursday. And that's pretty much it. If you like this sort of thing, please tell me how bad or good it was so we can make it better for the next class that we run here in Singapore. So if you don't mind filling in just like five seconds feedback, please do. And thank you very much for having me. All right, so that's...


This is a long walk. I don't know why I thought I had to walk over here to actually say hello. Hello. Howdy. I'm super, super honored to be here at WordCamp Europe. I'm disappointed in retrospect that this is the first WordCamp Europe I've ever attended, but I'm really happy to be here. My name, as mentioned, is Andrea Middleton. Like factual correction, I started my WordPress blog in 2006, but I was hired to work on community in 2011 by Automatic and focusing mostly on overseeing the WordCamp program for the past six years. And I'm really excited to talk to you today about the global community team. So what do we mean when we talk about global community, about the WordPress community itself? Well, look around you. This is it. You're in it. Done. I'm going to talk to you later. By participating in this event or by using WordPress in any way, you are part of our community. So that's it. You're on our team. Welcome. You belong here. The WordPress community team's job is to create community using the tool of these in-person live events. They are our code. They are our whatever designers use to make pretty things. What do they use? Pencils? I don't know.  So today, I want to talk about how we craft our events to result in the WordPress community that we're all part of and proud of. Our community team organizes a very specific, very special kind of event. They're informal events. This event, notwithstanding. They are organized by the community itself. And they're all about WordPress. They're put together by WordPress users, just like you. Everyone in here is capable of being a community organizer on our team. By the way, that's also recruitment. Please join our team. We organize these events, building these communities, using the same tools we use to build WordPress itself. If you're familiar with how the WordPress open source project works, a lot of the stuff I'm going to be talking about will look really familiar to you. But I realize there are a lot of people who have been welcomed into the WordPress space, who don't have a lot of experience in the open source space. So I want to do a little bit of background about open source. WordPress, this magnificent 28% of the internet, volunteer coded, volunteer organized project, was made possible because of the open source movement. And it has flourished through open source development. But what does open source really mean? Well, there's a book, a little book. I recommend you read it, called The Cathedral in the Bazaar. I'm going to summarize the message of that book. It's written by a man named Eric Raymond. And he describes the rise and growth of the open source movement, focusing mostly on Linux and then also a mail project that he oversaw and ran, kind of as an experiment. And the book details a new approach to software development that Linux and other projects like it proved could work better than the old conventional style of software development. He defines the two main methods of software development as the cathedral and the bazaar. I just remembered I have a clicker. I don't need to be over there all the time. It's going to be great. All right, so the cathedral and the bazaar.  We stick them in a room. We don't let them talk to anybody. And they work on a predefined plan. And they build something. And they perfect it and perfect it and perfect it until it's as perfect as they can possibly make it. And then they release the product. And they keep the nuts and bolts to themselves. Closed source is what it's frequently called these days. The bazaar method turns this all the way around. You publish the source code. You make it public for anybody to do anything with that they want. That's crazy. And you allow anyone who is interested and capable of and contributing to the project to help you build it. The open source method in many ways seems very ridiculous. It shouldn't work for a number of different reasons. Largely divergent agendas and approaches to one project doesn't seem attractive, right? And conventional wisdom tells us that frequently adding a developer or multiple developers to a certain project tends to slow down development rather than speeding up, right? But it does work. And it's kind of sort of taking over the world. Why does it work? I love these visual notes by Julia Forsythe. They're magnificent. For one thing, it really calls out the problem with the cathedral approach. Primarily the problem with the cathedral approach is that software, when it is written by people who aren't going to use it and kind of don't care, is never great software, right? The first and most important tenet of open source software is the importance of having users. You need to have and cultivate a large user base. And this is important because with many eyes, all bugs are shallow. Raymond calls this Linus's law after Linus Torvald of Linux. And the idea here is that when lots of people are using the software and lots of people are quite candidly complaining about the software, certain people, one person over here can say, hey, this doesn't work. And someone on the other side of the world can be like, oh, yeah, I've got a fix for that. Also, when you have vastly different perspectives on what's good about the software, what's bad about the software, and also what it needs to do, you in the end build a better product because the direction of the product is responsive to the people who are using it. When someone finds an error or a bug in an open source project, we don't tell them to shut up and go away. On the contrary, we're like, ooh, great. Bring it in.  Patch is welcome. We want you to be part of our team and help fix it. And because everything is public and open, anyone can learn how to provide really high quality fixes to the problems that they found. If somebody loses interest, somebody else who's more motivated steps up and gets involved. So you have a constant stream of interested, motivated people. Motivation, though, is interesting. Why do people do this? Why would anyone contribute to an open source project? Well, according to Raymond and a lot of other people, every good piece of software starts because someone is scratching a personal itch. One thing about this gets them really motivated and they want to change it. When they're passionate about the thing, they put a lot of attention to fixing the thing. And then they contribute it back to the overall software. And then somebody else comes in and says, ooh, but that's also broken. I'll fix that. And on and on and on. So we need people to use the software. We also need people to be annoyed with the software enough to want to fix it. But we don't want drive-by critiques. We want to keep people involved and connected. And that's why we always release early and release often. Rapid iteration is the key to keeping your contributors active and engaged. When they can suggest something and see it affect the overall project quickly and frequently, the imperfections don't matter because you know that it's going to get fixed soon because there's another release coming. And you know that what you have to say is important. You have a piece of this thing, and it keeps you in. And that rapid release cycle means that the project isn't ever perfect, but that's OK because successful open source projects avoid perfection like the plague. If you're building this bizarre, perfection is like a wall around that participatory space. You fix something, something else immediately comes up, and you cultivate that. The lack of perfection is not a problem. It's an opportunity. It pulls in future contributors. And as Andrew Nason mentioned this morning, thank you, Nason, for setting up my talk. It's better to have an imperfect project than to have a perfect product that nobody uses. And that's open source. It's messy. It's chaotic. But it's built on some central tenets of openness, transparency, collaboration, rapid iteration, and imperfection. Great, cool. But this is supposed to be a community talk, and you just gave us 13 slides about software development. Let's bring it back around. Let's talk about how WordPress community organizers put these ideas of openness, transparency, iteration, imperfection into practice in our daily work. So the bedrock of the WordPress community is the local meetup group, the local user group, which we frequently call a meetup. It's a group of people who work with WordPress in any way, bloggers, developers, designers, trainers, whatever, to gather at least once a month to talk about WordPress and share their knowledge. It's locally organized, meets face to face. Anything that brings two or more people together is a meetup. There's no minimum number of attendees, and there's no required format. In fact, we have a lot of formats. Presentations, social gatherings, hackathons, co-working, help desk, contributor days, so on. The model is open. Anyone can start a meetup group, and if you want to be part of the WordPress open source projects program and take advantage of the benefits that come with that, you can join our chapter account on meetup.com, pictured here. Official groups, when they come into the program, agree to follow five good faith rules, only wall of text in the entire presentation, I promise. But these rules, in their basis, meetups are organized to benefit the community. Membership is open to anyone. That open bazaar, right? No one is paid to build community, just like with WordPress. Anyone can organize. Any trusted member of the group can organize, and we create a welcoming environment. So what does that have to do with open source? Well, as you can see, these are pretty much the same expectations that you find when you contribute code to an open source project. Openness, anyone can join, events are welcoming. Rapid iteration, anyone can organize an event and experiment with models and maybe focus on subject matters that scratch their personal itch, right? That brings in more people that have something to do with their ideas. Collaboration, decisions benefit the overall group, no one is paid. We use these methods to build our community and to solve the problems that come up in community organizing, for example. I don't know if anyone's ever been to Seattle, Washington, anyone? I know we have a few Seattleites. Great city, huge tech community, beautiful. One big problem, well, multiple problems in Seattle, but one primary Seattle problem that I'm sure Parisians know nothing about, it's a lot of traffic. It is really hard to move around in that city. It can take an hour to drive, I don't know, 15 miles. And this was a problem for our local meetup group because they were holding a monthly meetup, sure, downtown. They had a huge list of people who were members of the group, maybe 900, I mean, ridiculously big. But only 15, 20 people could show up every month. This problem will not be a surprise to other community organizers who are already part of our team. This is a constant problem that we have in big cities, right? And it's frustrating because you want everyone to join. But at the same time, if you move it out of downtown, how do you keep the downtown people stressed, right? Because they're part of our program or as part of our program as an extension of our program, the group organizers opened the group and told everyone, hey, anyone can organize an event in our meetup. Doesn't have to be at a certain time, doesn't have to be at a certain place. The only requirement is you organize it and you show up to the thing that you organized. That's it. And in March, this is what their calendar looked like. As you can see, we've got what? Five different meetings a month, different times of day, different locations, different subject matter. All of those bring in more people. You have multiplied your inclusion by a factor of five. Openness turned complaints into solutions. The people who wanted something and were asking for it were said, yes, you can have that, but you have to do it. And it brings people in. With many eyes and contributors, all bugs are shallow. Another way that local communities attract more participants and give people more of a chance to get involved is by organizing a word camp. Word camps, you're soaking in it. Just like all WordPress community events are locally organized, volunteer-run events that focus on WordPress. A word camp is a little different from a local meetup in really only a few ways. It's an all-day event. Usually it's organized on an annual basis, but not always. They are the celebration of the local WordPress community. Unlike this event, most word camps in our calendar are between 200 and 400 people. And what we call the minimum viable product of a word camp is very simple. Four maybe five things. 50 people in a room all day long talking about WordPress. Number five that I highly recommend is coffee. So how do we apply our open source principles when we're organizing word camp? All right, let's talk about ticket prices, first of all. We had a little issue at word camp Europe. In that, I don't know if you heard about this, the people who are applying for visas to travel internationally to come here, some people got turned down because our ticket prices were too low. And a lot of people may ask themselves, why on earth would this event, this magnificent event, charge 40 euro a ticket? Is it because the WordPress project doesn't think it's valuable? No. That was a really obviously rhetorical question. Of course not. It's because this is a WordPress activity. WordPress is free. We want all of our events and everything that touches the project to be free and as close to free as possible and as accessible as possible. Nothing should get in the way of someone joining into our events if we can avoid it. And so we price our tickets as low as humanly possible. We do charge a little bit just because that way we're not throwing out about 400 lunches every day. But we price our tickets as low as possible to help create that participatory bizarre or make this an open participatory event. Let's take another example. WordCamp London organizers this year. Is anyone here at WordCamp London? So that was an event where the organizers got super ambitious and wanted to try out some new things and really experiment with the model, not entirely the model, but really add more things to their program. This is great. And we encourage it. And sometimes when organizers get ambitious, they get busy. And sometimes when you get busy, well, maybe it's just me. When I get busy, I make mistakes sometimes. And what was happening with WordCamp London early days is that they would be publishing early and often. And sometimes they would have typos or mistakes in their content. The organizing team from the beginning, though, made a very conscious choice to organize in the open. All of their discussions that they could do in public Slack channels and the local UK Slack installation, everything they could talk about publicly, they talked about publicly. And anyone could join those channels. So the entire community could interact with them very easily or about as easily as it takes to participate on Slack. And so what they found was when they publish a blog post with a little error in it, someone would come into the Slack channel and be like, hey, got a typo. And it didn't just happen once. It happened a couple times. And so there's a couple ways that you can approach this as an event organizer.  We need to get him out of here. And also, we need to slow it down and perfect our work so we aren't criticized. They took the other approach. They took the bizarre approach. And they said, you've got a suggestion. You've got a job. Welcome to our team. And they put him and they created a quality assurance place on their group. And that guy's on the team. And he helped make their product better, not by adding to their work, but by reducing their work and becoming part of their team. They opened it up. And I bet you, money, he is going to have a much more expanded role next year because he's had a good experience of being welcomed into the team this year. So where does this all get us? WordPress community organizing uses the same methods as the rest of the open source project. And building WordPress community is a contribution to the WordPress open source project itself, just like contributing code, just like answering questions in the support forums. Because we know that open source is built on collaboration and participation, let's talk very briefly about how community organizing helps the WordPress project get more of that stuff it needs. Participation is risky. It is hard to join a group. When you participate, you risk rejection and you risk failure. And I don't know about you, but I do not like that. People don't take risks when they don't feel confident. And people don't feel confident when they're uncomfortable. So one of the jobs of our organizers, the heart's blood of any great event organizer, is to tell people that they are equally welcome and important where they are. You're basically coding brains, right? You are setting up a live environment to tell people that they belong. Organizers in our program provide space that encourages connection within the event, but also encourages connection with the event, space to work on our events, space to work inside of our events, which is why the story of so many people in the WordPress community has a common phrase. I bet you've all heard it, and that is. And then I went to a WordCamp. Live events like WordCamps have been a turning point for thousands of people in the WordPress open source project. And I have another story for you. It's 2010. WordCamp, New York City. The lead organizer volunteered to do some design work. Now, this particularly lead organizer knew a lot of designers. Her name's Jen Milo. She's actually a very accomplished designer herself. But because she was right in that model of building that participatory bazaar, making everything open and encouraging people to take part, she made a public call for designers. And as you see, she doesn't just say, hey, we need a designer, folks. She says, we could use three designers if that's what it'll take. She lists out, these are the little jobs, and more or less how much time it will take to do each one of them. And says, multiple people are welcome to do this work. And Mel Choice's partner saw this post and said, Mel, you should do this. Mel had never been to a WordCamp before. She had never been to a meetup. She was just like, well, I like WordPress, and I like design. I don't know, maybe I can help. And she made her first contribution to WordPress as a volunteer on a WordCamp event. Very small. It was the batches. She helped design and make those building images and then composed that cityscape. And that's it. She got involved. She gave a little piece. She attended the event. That's her in the middle with that big, big, big, big smile. And she felt welcome. And not only did she feel welcome, she was a part of it. She had given some piece of it. And then for that reason, it was partly hers. And that kept her inside of WordPress, with WordPress, for, well, you're going to hear for how long. She kept designing and kept iterating. And two years later, she was a speaker at WordCamp Philly. Two years, transition from designing tiny, tiny bit of the event to becoming a speaker. And at that event, after she spoke, they had a dev day the next day, a contributor day in 2012. And at that contributor day, she made her first contribution to WordPress that made it into WordPress core. Someone there helped her work on the patch. And it was accepted. It was a small patch. It was very small. It was a small contribution. Again, doesn't have to be big. You don't have to rewrite something to be part of the team. But the very fact that she figured out, she got some help figuring that out, it went into core. It gave her confidence. It made her independent. So she was like, oh, OK. Now I know how this works. I'm going to go. I can do it. And now I have people that I can bounce stuff off of, because I've met people who want to help me. In the years that followed, Mel contributed to many efforts and many projects in the WordPress open source project. She contributed to MP6. She worked on Dashacons. She got a job at a WordPress company, Automatic, which is the same company I work for. And three short years later, she was named as a core committer for WordPress Core. In 2015, 1.4.5 was released. That's a lot of movement in five years from tiny little design contribution to permanent core commit. The next year, she led the design and development of 2017. And this year, she is the design co-lead for the WordPress Core customization focus. It all changed at a WordCamp. Two WordCamps, to be absolutely precise. A small volunteer opportunity brought her in. Another small contribution taught her confidence. But each of those events were key steps in her path to becoming a leader in the WordPress project. And without that program, who knows whether we would ever have been able to benefit from her perspective and hard work. So as you can see, in-person events are powerful tools for building that participatory bazaar. They create volunteer opportunities and personal connections. And those personal connections and eventually friendships do a lot of things for us. They help us step out of our comfort zone and speak up instead of lurking or just standing back and thinking, I don't know. I have a thought, but I'm not going to say it. They help us contribute and collaborate more efficiently. I don't know about you all, but I don't generally see the best version of myself when I'm communicating in text on the internet. When we see each other and meet each other, we humanize the person on the other side of that screen. And we help ourselves get past our conflict, or at least be more patient with us. It helps us reach out and get support instead of giving up. And generally, it keeps us all in. Not only that, but the project itself depends on local community organizers to deeply understand their local communities, to draw attention to all the ways WordPress is being used. Because that expands the community too. It helps the project grow. We depend on local organizers to say, hey, we're doing some cool stuff with WordPress over here, and we're going to tell you about it through our events. It helps us expand WordPress. So you're already part of our conspicuously imperfect WordPress community, and open source methodology is all around you. Every local WordPress community has plenty of interesting bugs and problems that you can work on. And as you can see on this slide, there are lots and lots and lots of ways to help. We need your eyes. We need your unique perspectives. We need your participation. And now you know our source code, so you are educated community developers. Please join us. Thank you so much, Andrea. I am such a lucky girl that I was allowed to MC here, because I wouldn't have wanted to miss this talk. It was so inspiring. And I really recognize so much things on your talk which fit to my own story. That was so cool. I will watch it again. So but I'm quite sure it's not only me who found this very inspiring. We have still some time left for Q&A. And I would like to see if there are questions in this room. We have two standing microphones here in front and two standing microphones in the upper rows. So please, if you have a question, move to the microphones so that Andrea can give you the answers. I can then ask you the first question. Oh, you were there. Great. Hi. My name is Dave from WordCamp Antwerp Belgium. What is your best practice for a multilingual audience like we have in Dutch and Dutch-speaking French? Also a German part. Well, this is pretty good right here. But this is an expensive solution, right? You know, we have been working on this off and on in multiple communities around the world. And I'm not sure we have established a best practice yet. We have a lot of different approaches. And I think they work well in different places. Some communities like to choose kind of a third-party language and have everything in that language so that nobody gets mad that it's in one or the other. Frequently that is English, but not always. Some groups like to do kind of a parallel, like two tracks, one in each language. I was talking to a group organizer the other day who asked the same question. And I suggested, well, I tell you what, open it up to the community. I'll encourage applications in both and see what you get. Because it may be that we're perceiving a problem where one doesn't exist. Or it may be you get half and half. And then the decision's pretty easy and you provide two. But more than anything, I recommend asking the community what it wants, asking your group, and gathering high-quality data from the community. Our job isn't to give them what we think they want. Our job is to provide a space where we make the room and kind of get out of the way. And they do the connecting that they need to do and want to do. OK, thank you. Yeah, great. Hello, Andrea. My name is Mauricio. I'm from the Madrid community. Oh, wonderful. And we have always the same problem because WordPress is free and also the meetups are free that people apply and we have a small venue, but they never show up. And it's a hard problem because we don't want and we can't put a price to our meetups and we don't know how to solve it. Yes, you are not alone. You are part of a large tribe of event organizers that is super annoyed by this. We were just talking about it in the community team channel. By the way, we have a couple of channels in Slack and WordPress.org Slack. One is community-team, and that's where we talk about all these interesting questions. I get that it's annoying when 100 people sign up for something and 20 show up. From a person who likes consistency and predictable information really gets on my nerves. However, sometimes the focus needs to be on the positive side, which is, hey, we got 20 people. And what I tell most community organizers who are facing this is track the data and see if you have any predictable ratio. WordCamp organizers can almost always guarantee that there will be about 15% to 20% attrition for every event. And when I organize WordCamps, I plan for that. I'm like, OK, so we have a capacity of, I don't know how big is this room, 2,000 people? And so I'm going to sell 2,200 tickets, relying on the fact that 20%, that's not 20%, is it? Percents are hard. I'm going to plan for that attrition and go from there. So my first recommendation would be, don't limit the number of places to the actual number of seats in there. However, there are also things you can do with community engagement to ensure that if people sign up, that they actually show up. Sending messages to people right before the event, following up with people in a super not angry way to say, hey, I saw you signed up and you didn't show up. It would really help us out if you could let us know that you're not showing up and stuff like that and just encourage best behavior. But it gets on all of our nerves. And unfortunately, the solution is worse than the problem. The work that we would do to make people be consistent keeps people out. So that's something that we tend to want to hold on to. I think we had over here first, and then we'll come back over here. About that, about that. It's OK. Sorry? About that issue, we filled it in Greece by providing free pizza and beer for everybody. Oh, food is a good way to get people to show up. I agree. And hey, look at that. Our participatory group is working, helping each other. Yes? Hi, Amanda from Cluj, Romania. I often find that meetup makes it a bit difficult to communicate with people. What other means do you suggest to bring people together or make it easier to communicate like a Facebook group? There are a lot of things that work well. One of the challenges in our program is extrapolating the way we do things to work in every single culture in the world. That is one of the biggest challenges that the global community team runs into. So I don't have a definitive answer for you. I agree that sometimes meetup.com communication tools are suboptimal. But what I do recommend is finding the communication tool that works and doubling down on it. Some groups really find that a Facebook group is very, very powerful for them. Some groups find that a proprietary website is powerful for them. Some people find that just Twitter, Twitter, Twitter all the time is the way. What I encourage people to do when they're thinking of solving this communication problem is make sure whatever decision they make, they make sure that the solution is inclusive and open. The problem with proprietary websites is unlike who has access to it and then what happens if the person who owns it wants to go to Drupal or something and doesn't care about WordPress anymore, how do you hand it off, all that stuff. So the solutions that close the group end up being more harm than the problem we're trying to solve. But honestly, I don't know where your community likes to interact as well as you do. Again, I hate to say it over and over, but I would talk to the group, say, where will we most successfully communicate with each other and follow their lead? Sorry, do I have time for one more? Yeah, yeah, one last question, go for it. Andrea, this is Anastasias. Following up on the previous question, I'd like to ask you, to your knowledge, has it ever worked to make a poster about an event? Oh, yes, yeah. We get really focused on technological solutions to what are essentially human problems. Flyers, posters, signs, I don't know, bumper stickers, whatever. Things that help people communicate, little flyers that people can leave at coffee shops, word of mouth, certainly, organizing a bring the friend event is a great way to expand your communication and expand your group. Yeah, don't just fixate on digital solutions. There are a lot of analog solutions that are super powerful. So that's a great point. Thank you. Thank you so much. We are done now, and it was a great talk again. I have to repeat that.  It was a pleasure to have you here.


welcome everybody welcome to sugar MD channel if you haven't subscribed yet by the way just do it right now today we are talking about dates no not the romantic ones we're talking about the dates that you eat or maybe don't eat but today you will learn if dates are really that horrible for diabetics and I'm not gonna give a conclusive answer but you will understand you will get what you want after this video so let's get started so guys the dates I love it do you I would say so let me know what you think write a comment below and give me what you think just be nice sometimes people put like weird comments and just being nice is always a good idea so but guys the dates are full of sugar right we know that but they're delicious we know that too now should I eat should I not eat should I eat should I not eat well debatable let's debate now one dates are around 18 grams of sugar carbohydrates right so you're gonna be like wow wow that's a lot well on the other hand remember when you eat fruit you are getting so many benefits you're not just getting sugar so you have to keep your mind open about things you know what is the benefit what is the risk nothing in life is 100% beneficial or 100% harmful so we live in a gray world in this gray world you have to choose your more white than the blacks and you'll be on the good side with the fruits guys especially the dates are so much antioxidants in it that negates that that free radical damage that may happen with high blood sugars now one of the primary things that you get with the dates is phylovenoids right so that is one antioxidants that make you live longer there is also carotenoids in this indeed dates and what what does it help with macular degeneration now you some of you may have it already you don't have to have diabetes to have macular degeneration but that is one of the most common reason for going blind and if you're eating steak and pork chops every day you're not gonna miss out on this one so you see what I'm saying so another one is a phenolic acid and that is primarily to prevent heart disease and cancer well think about this what do people die from yeah heart attack and cancer right so that's the two killers so you have to have this antioxidants in your system and it's not gonna happen without vegetables and fruits so tell your carnivore friends that endure your life for now but eventually you are going to suffer from the consequences from eating those beef and beef and beef every day morning and noon and evening so definitely I think if lice and mclaude is a little bit on the high side so I'm not saying sit down and eat like three five dates but if you're feeling like oh god I'm hungry no I don't have anything to eat right now I don't want to I hate eating these beef jerky's and the cheese I'm tired of it you know what one date we'll take care of it because there's so much fiber and dates that's not gonna necessarily spark your blood sugar and if you're eating one or two dates it's gonna give you this nice mellow sweet taste and it's gonna spike your blood sugar relatively slowly especially if you add some nuts to it again not nuts can be boring sometimes right like especially if it is non-salted if it is not roasted and stuff like that and when you're salt and roast the nuts there's really nothing much left you're basically killing the nuts but if you put those nuts in something delicious like dates oh my god then you have the bomb bomb.com right that dates that date that you're eating with some nuts could be Brazilian nuts, macadamia nuts, hazelnuts you name it put some nut to it it's going to give you more omega-3s more antioxidants it's gonna slow the spike of your blood sugar it's gonna give you a prolonged satiety that is like my friend do that again be in moderation if you are eating dates don't eat any other extra fruits and don't go overboard don't say oh dr. Ergen said you can eat mangoes now let me eat some mangoes on top of the dates and he said you can eat that and and then you end up with this huge bucket of fruits no that's not what I'm saying you have to control your portion size you have to make sure that your carbohydrate content over all your glycemic load is still at the reasonable range and if you're a diabetic that you cannot eat even one date without sparking your blood sugar then you pretty much have nothing left in your pancreas so that is not a good place to be you definitely need to see a diabetes specialist to get your life back unless you want to give up on everything you loved once upon a time that were healthy so talk to you later guys give a thumbs up we'll see you in the next video all right thank you for watching and I want you to be more informed and more educated so to do that go ahead and watch this next video right here


It is clear that this book is trash, but then I realized that it was written in Microsoft Word. You can really tell that the novel is bad because of it. If they use any other word processor, it would have been a much better story. When are lazy writers going to stop using Microsoft Word to write books? Oh, I almost forget to mention, this novel is just 500 pages long. 500. Why would I buy it so just short?