then. And we're live. All right, excellent. So having not prepared much, let's see on the fly. So let's talk about DevOps in general, where we've come the last year, where we're going, and then talk specifically about auto DevOps, and then open it up from there. How does that sound? That works. All right, cool. I think I already showed you this last time. The, what's a good place to start? Let's see my pull up our direction page, and then I'm going to search the screen. Okay, so from the direction page, this was, when I joined a year or so ago, I created a vision document for CI CD, and outlined a lot of the key things that I thought we're missing in CI CD in general, and going beyond CD is CD. I just called it beyond CD, literally. That's what I called it, because I didn't have a name for it. And I created this example pipeline to sort of characterize all the stuff. I move this is going to work. Okay, good. And so I mentioned this before, but the reason I love this diagram is not only because complex and scary, but also because when I started, we had maybe four boxes filled in, and now we've got 10 or whatever it is, filled in or 12 or whatever. Basically, we originally had obviously the code management. Can you actually see my mouse? Or is it? We can. Okay, good. So yeah, we had code management, and obviously build and tests. And we kind of did deploy, but not really. Well, since then, we've added review apps, which is really awesome. It's a specific example of deploys, but we also added, you know, more formalized mechanism for doing deploys and actually recording deploys and deploy histories and track of environments and everything else. And we added canary deploys in 9.2. We added code climates in, I think in 93 or maybe it was 92 even that slipped in, I'm not sure. But it was just recent. We added Prometheus monitoring at assist level, I think in 90 or somewhere around there.  That's coming, though. We don't yet have a plan for future flags, but I think it's a really important part. We have a plan for load testing. The Prometheus team is actually leading that, although there might be some things that don't make this related, but unless load testing is the first class thing. And then down here, we have this other sort of dimension of pipelines, which is a relationship of different code, code basis projects. And in 9.3, we're going to introduce the first versions of cross-project pipelines. So really going from, you know, a core thing of three boxes, actually, to whatever, 90% of this is complete. So that's pretty awesome. But it also became obvious that to me, at least, as we were looking at this, you know, I used to kind of think of this as a hard line of developer focused versus ops focused and thinking like, oh, yeah, we'll get you like up into what we'll deploy into production. And we might even watch the metrics related to your code in production. We're not going to just monitor your production app like that's operations. That's clearly out of scope, right? And what kind of hit me a few months ago is why is that out of scope?  No, we're going to keep going. We're going to go back, you know, past production into operations. Most of the stuff still applies. But it goes further and says, okay, well, not only am I going to be monitoring the system just as it relates to merge requests, what about monitoring the system for network errors, voltages, whatever, dependency problems, whatever, anything that is typically ops related that may or may not involve a developer at all.  Something went wrong. And it's got nothing to do with code. Well, in the broad sense code, but not your code, your project code. And, you know, Amazon is down, we've got to reroute to Google, whatever the heck, there's real operations stuff. And it really hit me that we really need to get towards that we need to go beyond that. And then that gave a little bit more of context for, there.  So maybe the whole thing is DevOps. I'm sort of really bring the question of, is there a better way to describe this stuff? Start with a little bit of meta here about DevOps. DevOps is hard to define because everybody defines it slightly differently. But in particular, there's two things that we sort of got to keep in mind. One is that sometimes people define DevOps as the intersection. So I actually look up Wikipedia, there's this little triangle here, or sorry, Venn diagram with a little triangle in the middle. And it's like, oh, well, DevOps is the intersection of development operations in QA, which is already confusing because it's not DevOps QA, it's DevOps. Why isn't it just the intersection of the two? But it makes sense, nonetheless, because actually a lot of this has to do with reliability of your code and continuous integration and all this kind of stuff. But so here DevOps is defined as this as the intersection. So there's trying that there's other things that developers do that aren't related to DevOps and operations do that aren't related to DevOps. And that makes sense. And so you then look at this, this DevOps tool chain definition, where they basically say everything from code to releasing to monitoring, that's all the DevOps tool chain. And so then it's like, well, that's everything. That's not the intersection, that's the union of everything. And so I think that's where things get a little confusing when we talk about DevOps. A long time ago, Hayden challenged me and said, you know, I think GitLab is the DevOps tool chain. In fact, then I was like, no, wait a minute, we don't do Opsie stuff. We're like the dev part of that. And, you know, we're it's way too early to do ops. Well, that's not true anymore. We are absolutely part of the DevOps tool chain. We do a complete DevOps tool chain is what I say. We cover from code to monitoring. And I shouldn't actually say complete. We have a tool chain of which you still probably are going to have other components. We're not everything in the shooting. We don't do Kubernetes. There's still parts of your DevOps tool chain you need. But we are a complete thing in the sense of end and from code to production to monitoring. And we do something in that entire spectrum. So from the tool chain tool product description, you can say, well, then DevOps means code control, building, testing, packaging, et cetera. But, you know, that means that everything, everything that we do, everything that a lot of folks do in this whole developer cycle and the whole ops cycle, that's all DevOps. So then again, you get to this nomenclature thing of like, all right, well, but when we usually talk about DevOps, we're not talking about all of your code stuff. It's intersection parts that are the interesting parts of DevOps. It's the parts where we let developers get their code into production easily. That slice, that intersection, you know, in the Venn diagram again, that's the interesting part about DevOps. Having said that though, still as a product company, we are going to deliver things that are pretty squarely in the development side. And eventually we're going to hopefully deliver things that are pretty squarely in the operations side. Where at some point we may have an operations dashboard that lets you understand your dependencies of your network infrastructure and your routers and your whatever. And that's pretty far fetched at this point. But it could happen. Like why not just have this V1 operations dashboard. And then it's not just about the intersection of DevOps, it's the whole DevOps tool chain. So anyway, at least just to get on the same page, there's the two sort of definitions of DevOps that I think are really interesting here. For the most part, my personal interest has been in the intersection pieces.  We've done that for quite a while. How do we get that code into production? How do we get it into, in fact into QA and with DevOps is a great example. That is squarely in that tiny little triangle in the middle.  QA people could be designers or product managers or whoever, but people who are not just the primary coders and that they can actually quality assurance, you know, or feature assurance or whatever, just otherwise test your application.  So that is whirlwind high level, sort of where we've been in a little bit about where we're going. There's, there are a few issues that we're tracking. I'm going to pull up a few of these because we can refer to them later. It's dashboard. All right, let's start with that. There's just big, another thing about ops features that I created a while early month ago now. As we started to look into, like, oh, we've got this monitoring dashboard, but it's still very developer centric. Well, what about taking that same content and slicing it from the operator's perspective? And so we get some of these ops view of monitoring and deploy boards. This is pretty hard to understand because it's intentionally convoluted to show you the complexity of the thing. But the idea is that as an ops person, I might have an overview. For a moment, ignore all this stuff below. Let's just pretend there's only four things. And it's just a really high level. What's the state of my production? You know, in thinking about it, from a developer, I can go into a project, I can then go into the environments and I can look at, sorry, first, yeah, into a project, into the environment, see the production environment for that project. I can see what the status is. But what if I want to see all production environments? As an operations person, I care a little less about the projects and I care about production, how is production? And so think about this as giving me the overview of production. And so all of these little boxes would represent production deploys of projects that you have in your given infrastructure. And again, it's explicitly convoluted because we had just introduced subgroups. And I want to make sure that this mechanism expanded. So even if you look at this, and then just ignore all this stuff below and say, all right, well, here's all these top level dashboards. And then here's like one level down, which is already still pretty complicated. But let's say your marketing organization had different properties than your other developer operations, whatever. And you'd be able to really quickly see what the status is. And if something's read, you'd be able to click down and see stuff. And you'd be able to see graphs like this, which again, we already provide, but from the other angle, where you're looking at it from a project perspective, or as a developer, I'm looking at the deploy, saying, oh, how did my deploy affect my performance? But this is going the other way around and saying house production. And how is anything wrong with my entire production suite or whatever. So this is actually really just sort of scratching the surface of ops views of things. But I think it's going to be really much, much more important as people brace DevOps.  Or frankly, in a lot of organizations, it's really the same people. And there are no separate operations people developers push code to production. And they're paged if something goes wrong. I've worked in that environment where we basically disbanded ops. And it was awesome. And incredibly hard in some ways, it was a hard transition. But DevOps also totally different dimension but has multiple definitions there like is DevOps, the developers and the operators, or is it one person now fulfilling two roles? At any rate, either way, you want to be using the same tools and you want to be able to point to whatever a memory bump here, for example, and your operations people should be able to see that same memory bump. But if they're using completely different tools, they're using New Relic and Datadog and whatever, that kind of sucks. So let's give them the same tools. This is just a slightly different view, actually of kind of our existing environmental stuff, but just merging the stuff a little bit better. So you can actually see the health of each pod. This is more another sort of ops view thing where there's multiple pods running your production environment. There's no single memory usage. There's an average usage or a max usage, but there's lots of different pods all with their own middle memory usages. And in fact, there could be like one pod that has some, you know, egregious amount of memory, but of course, in GPU or something, there's something wrong. You know, that's going a little farther than we've really planned right now, but the idea of like digging into pod health and all this kind of stuff, but that will come. Let's see what else there is. Doesn't have any pictures. It's not good to talk about. I think there's another, let me dig into some of these because I think some of these are awesome. I particularly love this proposal and I really want to see this happen soon actually. So we currently have environments. If you haven't seen one, I'll let's see. I know I just made one. I literally just gave this demo a long ago. So this is what the environment page looks like today. It's just a list of environments with, you know, the last deployment, which the number doesn't really mean a lot, but the picture might tell you who deployed. So that's good. The commit. So here I can see that it's running the same shot as staging, which is kind of nice. I can see the deploy board and I can see, you know, that this has been, if there was a deploy ongoing, I'd be able to see the state as this rolled out. We don't currently show you the health of these pods once they're deployed. That's all we know is that they are deployed, but we have discussions at least of how to like, oh, well, if a pod is failing, we can sort of, so this is all, this is how the environments view is today. It's centered around, you know, sort of the deployment history. And if I click actually on, there's nothing there. Let me click on this one. Maybe there's always two deploys. So here there's a history of deploys. And this is actually really valuable because I can see who deployed things, how long ago. So if something went wrong in production, I can see like, oh, it went around. There's two hours ago that this happened. Okay, great. Who deployed something that it's a roundabout way of digging into that information, but at least you have it today. It's also really great for being able to roll back really quickly. If you do find a problem in production, I can just really quickly roll back and then let developers have some space to go and figure out what went wrong. But I can at least go back to a known good configuration. But this issue turns all that same kind of information, turns it around, and has frankly more of a DevOps view of the thing. The idea I take the same application and instead of just looking at a list of environments, I'd be looking at columns. Okay, that alone is such a big deal. This example happens to show two staging environments. You can even just ignore that for simplicity and pretend there's only one. But there would be lots of review apps and some number of staging environments and production environment. What's cool about this though is instead of just showing you the shaw, we would show you what merger quests have emerged into staging that are not yet in production. That's a great marriage of these two views that you'd be able to see the diff between them. It seems this works better. I'm actually losing my voice, wow. Nobody, I don't have larynxitis. We'll see how long this lasts. So seeing which merger quests are there, you know, because you can already do a diff and you can look at the commits and you can look at the commit messages and stuff. But really this marries a couple of awesome needs of information like we think in terms of merger quests awesome. I look at functionality groups of functions and say, this feature has been shipped into staging but not yet in production. This list, although it's just a mock-up, it shows the exact same information, would show you maybe the last five things that were in production or what was included in the last deploy or whatever it is, whatever works best for your environment, maybe even because we don't deploy that often. So showing just what's in the last deploy might be enough but for people that deploy 17 times a day, maybe that's a little less useful and you just show a history. But then we also build in a little bit more of the operations kind of stuff and say, all right, what's the state of my pods? Here we're flagging one, we're error rate exceeded something, there's some alert that popped up and here we're showing this automatic rollback kind of stuff, whatever. But basically just really building in this ops view. Of course, this is still a dev ops view in the sense that I'm looking at an individual project and looking at all this stuff. So one permutation of that would be what would this look like for marrying that sort of the ops view of all the production where am I at or I'm looking at maybe a microservices kind of thing where there's five or 100 different projects and I want to really quickly see the status of all those. I think this one's got a mock up. It doesn't look as impressive, frankly, because I just become sort of a matrix of stuff. But from an ops perspective, this could be really valuable and it just really quickly gives me the status of staging production at least. They may care a little less about review apps from an ops perspective, but certainly being able to see really quickly what's the status of my production fleet, what's queued up to go into production, what hasn't been deployed yet, etc., etc. So those are some of the concrete ideas we have. I think, you know what, let's go through some of these other ones because there's some other cool ones in here too. It's all future stuff. This in particular is unplanned. This one doesn't have, by the way, does have mock-ups down here. Let's go to the last mock-up. So here the idea is that you've deployed something in production and some module or whatever that you depend on has been updated, not by you but by the community or whatever. And so we would automatically, so there's multiple levels to think about this, sort of the easiest and most naive way is to say, on the next merge request or next CI CD run, we would go and check to see if you're testing something, to see if anything's outdated. And we might fail your CI CD and say, oh, you've got an outdated version of, in this case ES6 promise. And maybe that wouldn't be a fail normally, but let's say it was a security release. Maybe like, oh, well, let's fail that because you haven't updated. That's kind of lame because it's like, wait a minute, I'm working on something unrelated to this thing.  That doesn't make any sense. Wouldn't it make much more sense to just run this stuff automatically? And even if, for example, nobody pushes for seven days, in the middle of that, there's a security release of something. You should just proactively run stuff and notify me. So that's sort of a second iteration of thinking about how you would notify somebody and tell them, oh, you know, you've got a security change. You should go and do something about it. But then it's like, all right, now the third iteration is like, well, what would you do with that information? You'd go and maybe give it to your junior developer to go and make the change and point to the new version, you know, like this, you know, literally it's, oh, you know, change the Semver, bump it up to the next model version. And then, of course, you need to test that that works. So you're going to create an emergency request. And then test to make sure that it still functions properly. But like, well, why notify somebody and tell, you know, your junior developer to go and do this? Why don't we just do it for you? Why don't we just go and submit this merge request for you and then tell you what the results are? In fact, let's go further and say, hey, it passed. We just deployed into production for you.  You know, so this goes from sort of the alert kind of mindset to you go to work in the morning and you just get an email saying, like, oh, production has been updated for the security release. And so even when these really huge like open SSL security problems kick in and everybody's got a frantically scrambled to fix it, like, why don't we just fix that for you? And of course, because you trust your CI, it would automatically deploy to production. And if it didn't, then you'd finally get the alert, you know, so instead of having an alert about 100 projects or microservices on all me to get updated, you just get alert about three of them to fail, that actually have some weird dependency that it didn't work on. And then you can actually focus on, you know, real problems. So that's sort of a glimpse at how we're thinking about this. This would definitely be an enterprise level feature. And again, it refreshed out some ideas, but it's unscheduled, but does really tie into the ops mindset. And I don't know if this has much, I think this is just talking about how we'd auto revert something. We've got a quick question. Sure. You mentioned that that that sort of automation would be definitely like an enterprise edition feature. Can you can you talk a little bit more about why like a smaller development team like under 100 developers wouldn't get value out of? So this is where things got a little tricky, because yeah, of course, smaller developer teams would get value out of that too. Everybody would get value out of that. Some of it has to do with sort of proportionality or whatever. One test I like to use is is there's some other way you can achieve the same thing using workarounds or whatever. And we're just making it easier. And that's a good case here. Like you can already do this. You could clearly manually do all this stuff. We're going to automate it. And automation is something that affects larger companies a lot more because they've got hundreds of projects with thousands of developers or whatever it is, and they just can't deal with the scale or it's worth dealing with the automation. But if you've got a small developer with a single project, like you're pretty much on top of it and if something changes, like yeah, you just go ahead and you're aware of it. The bigger challenges are when you're just not aware of how this thing might affect one project somewhere that you've almost forgotten about or whatever. The other thing is that, well, I don't know, just to be blunt, that I think our concepts that Enterprise Edition is only for if you've got more than X people is a little flawed. Instead, it applies more to those companies that those people value it more, whether they'd be willing to pay for it more, however you judge your value there. Clearly, small companies would value all this automation and everything else, but they're not going to get as much incremental value out of it as electric computer would. The other way to look at it is just that this is pretty advanced stuff, and frankly, it just doesn't deserve to be free open source. It's probably really complicated stuff that we're going to have to do there. Maybe there'd be levels to it. There'd be a version that says, yeah, you'll get an alert. We'll run this test once a day, or maybe we can just have a blog post about how to do this. You set up a recurring scheduled pipeline job that once a day tests to see if any of your dependencies have been updated. You could do that today, and then it would alert you. But to automate it, to actually create the merge request for you and everything else, well, that's in the Enterprise feature. It's not that version checking isn't important for everybody, but the automation around it really, really matters for a lot of things. Does that make sense? Yeah. I mean, I think the first way you described it, and that like, yeah, everyone gets some value out of a feature like this, but the overwhelming kind of value and use for this is in kind of larger development teams, like that resonated. Okay. So then this is just a feature showing how we're thinking about, we've got this canary deploy, and we have another feature we're not currently working on our schedule, but it's incremental rollout, so that it would not just roll out to a single canary or a bucket of canaries, but it would just slowly increment and go to 1% and 5% and 25%, whatever it is, increment your stuff. But let's say at some point, during that rollout, you detect an error. So this is a mock-up of what it would look like and be like, oh, error rate increased by something above our threshold. Let's revert that one, go back and create an issue or whatever it is, alert somebody to take a look at it. Lately, I'm thinking, I don't know, I really want to automatically roll back versus just stop it in its canary form and say, well, it's canary, let's let the canary be there so you can debug the canary, but just don't let the canary go on further. Because sometimes, error rate exceeding is a pretty tough one, but let's say memory bumps up, and you might be like, yeah, we added something and it's using more memory and we're okay with that. Don't stop my deploy just because it's using more memory, but there might need to be human intervention in that. But anyway, but somewhere along this line, automating a lot of this deploy stuff, pretty cool. I think I already talked about this, but basically, yeah, there's no visuals, but just not just showing the status of the deploy, but setting status of each part. So that's it for that ops feature stuff. But then there's another meta issue for um I did not come up. Let's see if I can get to it through there. Nope. It's in the C. Yeah, I guess it's in the C, but okay.  And most of them are related to DevOps. Onboarding and adoption. There's just a whole bunch of areas there of it's actually a really big issue with lots of stuff just really show quickly show you the list of things. Lots of different ideas for how to improve onboarding, how to get people actually using idea to production, improving auto deploy, whatever. Not a lot of visuals. I won't really talk about it, but it's definitely one of our top areas. The next most important thing we're working on. Cloud development is this idea that you know, setting up your local host machine is actually kind of a pain. Um, sometimes if you switch between especially with micro services where like each service could be in their own language, whatever, like you don't have to want to maintain like Java and Ruby and Node and all these other versions of dependencies and every time something switches, you got to reinstall a new version of stuff or or whatever. You know, even just these days, it's developing on an iPad and they don't have a local host to compile things. Um, cloud nine is sort of the biggest well-known thing from an IDE perspective and Amazon bought them a little while ago. But even aside from the IDE portion of it is just being able to develop in the cloud and being able to make some changes and then push them back, you know, commit them to a repo. And we sort of have a little bit of a demo like this right now with our web terminal. So if you're on Kubernetes with this terminal button and it just pops up a terminal right in, I'll show you that if you haven't seen it. Yeah, here. So on the staging app, I just popped up terminal and I'm in the staging server and I could actually go ahead and, you know, edit a file there and I'll show you all the way through. So and I just made a live change into my staging app. And generally speaking, I would not actually recommend you do that because I'm messing with my staging app. That's not what this is for. Makes an awesome little demo, but it's, you know, it's not what you should do. What we want to do is come up with a way where people could do that, but have it be not on your staging app, but in maybe a cloud environment or dev environment that is specifically for this purpose. But that also lets after you make your changes and test them and run them live, you can then go and commit them back to version control and close that loop. So there's a whole bunch of issues related to that. And, you know, to be honest, it was what we were hoping that coding with a K would have provided for us and we have, you know, an integration with them, but it hasn't worked out nearly the way we had hoped. And so we're looking at, you know, alternatives and we think we can probably do this ourselves. Anyway, that's a big thing to flesh out. Ops features I just talked about. That's another big area of DevOps. There's several more here. We're going really quickly. Get out of paths. This is basically the idea that, you know, at some point, like Heroku is awesome because it gives you this really great platform that's easy to use and gives you all this functionality on top of Amazon and makes it, you know, and five or six years ago, it was like super like brain melting, you know, awesome to get people to do ops and do ops. So as a developer, I don't have to be aware of how do you even do ops? Like, Ruby just does the ops for us. And the idea here is that, like, you know, we've got a lot of these components and we're not going to invent them all from scratch. We're going to rely on Kubernetes, for example. But on top of communities, we could make an awesome environment, an awesome ops environment or a platform as a service. And so there's an issue there to discuss, you know, what it would take to do that. I don't bold with it because what I've done here is these three are the things that I want to work on a vision for right now. But just at some point in time, this is a big item for us, you know, if we can make it super really easy for you to, you know, just really fully manage your ops environment via GitLab and maybe like, for example, never touch the Kubernetes dashboard, never touch any of the tools, just use GitLab tools to do this. That's pretty powerful. Sort of related is actually an idea that's in the onboarding stuff. But the idea that, like on GitLab.com, we can actually provide you a Kubernetes cluster, or maybe a shared cluster. You have to worry about security and this kind of thing.  Oh, and I also know how to test Ruby apps. I'm just going to go and test them automatically for you. And oh, by the way, I know how to deploy this. I'm just going to deploy this to production. And we'll make a production dot, your project name dot, you know, ephemeral, GitLab apps.com, whatever the hell, some domain so that it's not going to affect actual production. But if you wanted to, you would just point your DNS over to this production app, and you've got your production app running on GitLab infrastructure. And that's really what Peroku provided, right? But that also is an onboarding thing, that we just make it really easy. Because if we want everybody to have CI, well, let's just turn it on for you. That's pretty awesome. But if we want everybody to have CD, we can't just turn it on for you because you have to have a place to deploy it too. So if we just provided you a Kubernetes cluster, everybody gets a cluster, then you just got a place. Now, maybe we'll severely limit it. We'll make it limited in some way so that you're not going to run your production stuff for long there. Or if you do, you have to pay for it, whatever. But we're not going to try and make money off of the production resources. We want to make money off of making it really easy. So really, what we want to do is encourage you to then go and spin up your own Kubernetes cluster, ideally on, say, Google, and we'll make a nice little link that says go and spin up a cluster on GKE We'll make that really, really easy. But to make it super easy for a first, you know, for some number of days, we could just provide you that cluster automatically. Anyway, so auto DevOps, we're going to talk about in a bit, so I'm going to jump over future flags. We just talked about briefly. I feel like I might have talked about them last time. So I'm not going to go into too much detail, but just they're really about decoupling delivery from deployment. The idea is you make your code, you deploy it, but you haven't turned it on. So it's not delivered yet. And the idea there is that it means you can merge in the mainline more often because it's not affecting anybody. But it also really helps because you can do things like, when I do deliver, I can deliver it for certain people, like just get lab employees or just the beta groups or whatever. And then I can control that. So then if the error rate spike or whatever, like, well, it's just a few people, I know who they are, they're going to complain to me, it's not a big deal. But I can test things out, get it polished, fix the problems before rolling it out. And then you can also do things like roll it out to 10% of the people, 50% of the people, whatever. It's all about sort of reducing risk, improving quality, and fundamentally by getting things into your mainline quicker. So it's ops-ish in that sense. It's really still pretty fully on dev. Version checker I just showed you, artifact management, this has become a hot topic lately. We already have a container registry for docker image artifacts. And we also have file-based artifacts that you can pass between jobs and pass between pipelines. And you can pass between cross-project pipelines soon. And we have ways to download that and browse them. But if those artifacts happen to be things like Maven or Ruby or Node modules that you want to then publish and release, and then consume in other pipelines, we don't have a formal way to do that. And you can obviously publish to the open source Ruby gems, for example. But if you want a private gem that is only consumed by your team, and Ruby developers maybe don't do that as much, but Java developers do that all the time. A lot of Java developers use Artifactory or SonarCube, whatever. And so anyway, in order to complete this toolchain thing, the idea is that we need to have some first-class support for that. Either by bundling in one of these other providers, or by just adding layers and APIs on top of our existing artifacts. So my personal pet favorite right now is we already have artifacts. But let's say you can just tag those and say, oh, this is a Maven type of artifact. And then we expose that via the API. And so then you can declare that in another project. And it would just consume the APIs and it would just know how to do that. But it would also use our built-in authentication. So you don't have to set up creds and do all this declaration. You can just be like, oh, I've got access to this project and this project so I can get the artifacts and I can just consume it all really easy. So those are the high-level things that I think are big ideas for DevOps. So let's talk about auto DevOps then. And this is actually really spanning from the near term to the very long term. But the idea here is that it's great that we do a lot of DevOps. Sure. And in a very simplistic way, it's like, oh, but shouldn't we just make this stuff automatic? The way I'd phrase it as we should provide best practices in an easy and default way. So the idea is like, you can, right now, you can set up a GLab CI YAML, but you have to actively go and do that. But really every project should be running some kind of CI. So why don't we just, again, detect when you've pushed up a product, project, sorry, and it's a certain kind of language. We'll just build it and we'll go and test it because we know what to do testing. And so today with auto deploy, we can already use auto build with build packs. So this, the link is actually to our production stuff. This works. We will automatically detect, I think, one of seven different languages and automatically build your Java app or your Ruby node. I forget what it may be. Go. I'm not sure which ones are in there. And we use Heroku's build packs actually to do this build. So we build that up. And then if, again, using auto deploy, we'll go ahead and deploy that. And so that's, again, pointing to actual documentation. This is a real thing. You still have to obviously have a communities cluster and do that. So it's not fully automated if you don't have that. But if you've got communities, like, hey, this is a one click, one click to do it. I can't really show you right now. But it's really easy. It's just literally one click. You pick from the menu. Oh, I'm on communities. And then pick submit and you've got auto deploy and auto build. One of the things we don't have is auto CI. And so that's a little annoying, but it's one of the things we want to pick up. And actually, hopefully, Dimitri, or CTO Dimitri, is going to pick that up in the Q3. And looking at using Heroku themselves actually extended build packs to do testing. And so that means that there's at least five build packs that know how to test these languages. And so like, hey, let's use that. Just automatically that. But even if that doesn't work, there's a lot of other things we can do. Other companies have all this stuff automated as well. So even if we can't use Heroku CI, being able to say, oh, this is this language, we know how to test this language, making that automatic. And then, again, either it's automatic is multiple levels of things. It's like, is it a wizard that configures this stuff for me? Is it a one click checkbox that says, yes, turn on auto CI? Or is it templates that I can easily add into my GitLab CI demo? I think in order to qualify auto, like, part of the idea here is that it shouldn't be templates, it shouldn't be blog posts that tell me how to do it. That's just CI. It should be like, literally just I pushed and it worked for most of you know, a checkbox or two. That's the idea is that all right, well, let's let's go further. What other things can we just automate here? And not automation for strictly the purposes of automation, but about bringing best practices to people. So you actually work hard to turn these things off. If you don't want CI, it's right off as opposed to like, yeah, by default, you should have this. So, you know, this is a really, really long list of things that, you know, when you think it's for everybody to get to the first ones have links because we're actually tracking, you know, more closely real, real issues for this, you know, auto metrics is a great one. Like, if you're running certain languages, we should just be able to, you know, really easily go and just pull the right information out of there. But, you know, whenever it goes on, the list is huge. But the idea is that we can build up this auto DevOps, even a marketing term and start talking about it in that way. And so not just say that GitLab is great for your DevOps and is a complete DevOps tool chain, but in fact, we do all this stuff for you automatically.  Like auto deploy is a great example, like that only works for web apps. It's not a web app, we can't just deploy it. Like what would it mean we deploy it and like it just wouldn't function? You know, if you made a command line app or whatever, like what would deploying even mean? Or if it's again, like a Maven or really any kind of like module that you bundled up and released, like, well, that's not the same thing as deploy. So, you know, maybe we need an auto release, it's not on this list, but maybe it should be. But within the web app space, we can do some of this stuff automatically. So, that's it. Everything you ever wanted to know about DevOps. Questions? None on my end. It's a lot to take in. I don't have to master it all right now. Mark, do you have like, so looking at this list on auto DevOps, I know you talked about, you know, some of them are sort of in process or in sort of thinking about designing, you know, do you have sort of a master plan in your mind is to sort of, you know, when this all gets built out and added into the platform? It's a good question. I think that the onboarding stuff that I talked about is our next most important thing to work on, or the most important thing to work on next. And that will start touching on some of this auto DevOps stuff. Like, ideally, I think one of the best ways we could onboard somebody is to just give them CI. And again, maybe we can't do auto deploy because you don't have Kubernetes, but we've got shared runners for free. So, just turning on CI for every project, that would be pretty awesome. And so, if we just auto built an auto CI, that still might take a few months, but that would be great. If we go further and add Kubernetes or cluster built in or whatever, or just maybe we can't automatically give you a cluster, but we make it really easy for you to create a cluster. And then once you've got a cluster, we can then turn on the rest of auto deploy and auto metrics and everything else. That's all pretty medium term stuff. I did say that like cloud development, if I go back to, let's see how far back was it. Yeah, right here. Like, these are the three things that I want to work on, you know, basically in order. Maybe I'll actually swap that order, frankly, as I look at it. I think I want to work on ops features before I work on cloud development. I think that there's a lot to be said for going after the ops operator, the ops person. And so, you know, I think that that's a big chunk of stuff. And that would really make a big difference in fleshing out sort of the DevOps, not auto DevOps, but just really focusing on DevOps. The rest of these things there, I really don't know.  And then some everybody says, well, when we decide to do them, we'll come up with something in a month, we'll ship it. Then three months later, we're going to have a pretty good version. So it really just kind of comes down to sort of what the priorities are. And it's too hard to play crystal ball on that. By the time we do these other things, that could be three or maybe six months of work, whatever. And even as I say that, part of me is like, well, we could do one month of work in each one of these things and then circle back around. And there's something to be said for that.  So yeah, I would have said, for example, if you'd asked me that original diagram that I showed with the big scope, if you said, how long would that take? It's like a multi-year thing. I would have never predicted, frankly, that we would have shipped as much as we shipped in the year. And that's a testament to our velocity, but also to focus and really and really said having this massive, great vision of delivering all this stuff and really pushing hard to deliver sort of minimal viable changes for each of these things and then adding to it later and believing in the breadth. So now that we've identified that DevOps is part of our breadth and ops is part of our breadth, I just I can't see holding back and ops features to me seems like the logical next thing after onboarding. Mark, I had a question. I can't remember if it was you that mentioned it or if I shot someone else, but I thought we were going to have a license checker for open source software. And would you include that in this whole kind of macro, big ITP areas of focus? Yeah, I think so. I mean, I called it version checker because that's this issue actually is a flow that I wanted to demo out and it was very specific and it was about versions. I think license checker is a little different in that you don't need to sort of proactively go and check every hour to see if the licenses change because for that matter, if you bundled it up and it's got a license, that license is the license. So license checker is more like when you do a new merge request and you add new dependencies, are those dependencies valid licenses? That's where you'd want to check it. So it's more like just a job in your CI-CD pipeline that just checks for any new modules, if none, great. If there are new modules or new dependencies, then check the license of them. But to do it right, you don't necessarily want to do that manually in your job definition. So I could easily imagine wanting to automate some of this stuff or do periodically audit existing projects or things like that. So you'd want one big button that would say go and check all my projects to see if they're compliant. At any rate, it definitely is in the realm. It's less DevOps-y then in the sense, but it's not strictly about writing code and hosting it. Thanks. Joe, any questions? I think I'm good for the moment. Thank you. Appreciate the overview. It's great. All right, cool. So I want to reserve the right to come back to you shortly. Of course. Yeah, so one of the questions, sort of the immediate things we have is this auto DevOps and it actually shows up in our OKRs currently. So from a product and marketing perspective, is this the term we want to go with? Is this a big thing we want to push for? If you want to push for that, how much product work needs to rally around this? That may mean shuffling around our priorities a little bit to get to a core thing that we're comfortable calling auto DevOps. Clearly, I hope we don't have to have all of this before we call it auto DevOps, but if you say, oh, we've got the first five items, then that's enough to call auto DevOps, but the first four isn't, in which case, maybe that means we need to shuffle some priorities. I think things are actually lining up, though, because, again, Dmitri's going to pick up auto CI. So that's one of the big things, I think, from this perspective. But anyway, we need to sort of circle around and talk about whether we want to market it as such. If so, how does that translate to products? And is it a feature? Is it a product? Or is it a white paper? I don't know. Like, where does it fit? That sort of that macro issue is one of the top ones for me, because we also have a lot of terminology floating around, right? And so, like getting consistency around, how do we talk about these things? How are we messaging them? So not only auto DevOps, but all the different concepts that we have from conversational developments, idea of production, you know. And so, yeah, anyways, one of the first orders of business. So, yeah, got to figure out sort of how to tackle that, but expect to work closely with you as we sort of ideate around that. Cool. All right. Well, if there's nothing else, we have three more minutes back. Great. Thanks, Mark. Really appreciate it. Thanks, Mark. All right, yeah, no problem. Of course, we have any questions? We'll do. Thank you.


When I got to prison when I first came to prison from youth authority, I was young Marr.  Man since I've been by the grace of God I've been home since 1995 I went to the feds for a year on a fair to communicate and After that I've been I've been out about 26 years and that's the part what I think people don't understand You've been out for 26 years you out here maintaining. You know what I mean? I think that's something to applaud You know what I mean because you before that you was out. Were you in and out before that? Mm-hmm And and so what made you what made you get it right? How did you get it right? I think that would be some people will want to know I mean I got it what it wasn't that I got it, right I just when you get tired of being tired, you know if your mother it's about you know People can pray for you and I can say that I'm gonna get it right and I guess it before God see you'll never change a man until he changes his own heart. Yeah, and When I got to prison when I first came to prison from youth authority, I was young marr I was a youngster putting it in and by 95 I was old dude and pops Now I'm in prison with dudes that I was in their sons and their grandsons Wow And I found out that I had outgrew prison If you ever say I had an incident one time when I You know when I grew up it was from the first grade to the sixth grade was elementary. Yeah, you went to junior high Yeah, yeah, yeah, that's it. That's it when you was in the sixth grade you was the boss of the school That's right. So one day I we were getting ready to go to recess and I snatched the ball and My teacher told me Marvin put that ball. I wanted the ball first. I'm now I'm rumbling for he takes me to the principal office Go to the principal office. Mrs. Thompson. Martin. What's your problem? I'm pouting He's a woman since you want to act like a third grader. I'm gonna put you in the third grade And he sent me over to miss Holmes class in the third grade So when I sat down my knees was touching the punch. I was too big Right, and if you're talking miss Holmes, it hits you with a ruler And I got I was going home and all the kids is telling hey Your brother's in the third grade like and it was just a Torturing week of me. I man. I'm out of place here Man, so after 25 years in prison, my knees start touching the bench Wow, and it was time to go You know A man told me one time one of the first black business owners of Compton on on the main stone Compton Boulevard named Ronald Exum He had Exum styles back in the 60s. Well 69 6869 that he got a clothing store like y'all's clothes But it was the first black entrepreneur on Compton Boulevard before white flight, right? And he told me he said man, you're going in I was about 15 Tell me you're going in out of juvenile man. You're going there.  I couldn't imagine that if you Right and it came to pass that my sister had gotten killed in 1982 and The guy that was accused his brother was in the same prison with me and Me and my crew was getting ready to go handle that little bit of business and a brother that I was in the nation of Islam What from the 60s brother yourself? Man hold up, bro. We got enough. He said why don't you do Ramadan with us?  So so this is the spot. I went in Did the Ramadan and I'm doing Ramadan and listen the nation of Islam and the Balinese and new Muslim And we didn't have none to do them We used to call them Abadabas and soft Muslims steal smoking cigarettes and eating hog and doing five prayers a day Then you got no discipline, right? So I went in there But it's every day we do there a 30th of the Quran and we read in the Quran and and so surah 62 It says that a woman suckles a child for 36 months and A man achieves manhood at age 40 So the same thing you did at 20 you don't do it 40 you start looking both ways, huh? Your thing ain't as quick as it was when you was 17 18.  In San Quentin they got what calls citizens row West Block Everybody over 25 30 years the old men is over there old men for counsel young men for war and She knows Elm Hall All the handicaps and the old people Dude like Bob Wells. He was at the time. I was in prison. He did one of the longest times He did 42 years and he's have a cane and be cussing like a sailor, right? But so I'm just saying when you get to a certain point in your life You Start living a different life if you a man of any virtue Some people try to live their 16 year olds as a 60, you know, right? You know, why are you trying to act young? I don't act young. I just be down with who I am Yeah, we on boss talk 101


Welcome to the World Summit on the Information Society 2017 here at the ITU headquarters in Geneva, Switzerland. Co-organised by ITU, UNTAD, UNESCO and UNDP in collaboration with all UN agencies, WISIS is the world's largest summit dedicated to information and communications technologies as a force for good. Over the course of six days, more than 2,500 participants from more than 150 countries will exchange knowledge and experiences working together to achieve the United Nations' sustainable development goals. We are strategic partners of the ITU, and WISIS is the exhibition on which all the ministries of communication and communication are represented. Throughout the week, participants from government, civil society, the private sector and academia will focus on sustainable development trends and inclusive ICT initiatives. We are having a lot of exciting things happening. Yesterday already we started with the hackathon and dealing with the solutions for the health. Of course we will have the release of the 18 winning prizes which will be awarded tomorrow during the opening ceremony with a special recognition for the prominence and for the best practice in the world in the implementation of the projects. There is generally a focus on innovation this year, a key sustainable development goal. Other priority areas like health, education, gender empowerment, the environment and infrastructure will also be discussed at more than 160 sessions and more than 200 specialised workshops. I can see two main roles of ICT in the sustainable development goals. One is the role of enabler, and the enabling role comes with innovation being able to achieve more with less. And that resonates very well with developing countries where we have to get to where everyone else but using much less means. The other role is an accelerator. We know that the ability of ICT to shrink distance and to kill time, if you apply that power to the different challenges that we are facing as we work towards the sustainable development goals, we're going to be able to achieve those results much faster. Don't miss this opportunity and join us in person or remotely, because more than 40,000 people already today followed us remotely and many more will join us tomorrow when the opening will take place at 9 o'clock here in Geneva.


So we've talked about alpha beta pruning. We walked through a few examples, but you know You were computer scientists and this is probably because you need a grade that you're like give me I how do I build this? I need to build this in my language Well, I'm not gonna just build it for you, but I will at least point you in the direction of Swat of what is a swathmore college? I really like this link in the description below But I really like their pseudo code because it helped even me sort of kind of really wrap my brain about this so What we're looking at here is specifically when we're dealing with alpha beta minimaxing, right? We're dealing with a function or method, you know again your language of choice But specifically looking at all of these different actions You know these different sort of categories of what's going on along the way Might help sort of give you some kind of guidance on what we're dealing with here So at least to start one of the things that they're sort of touching on is this notion of having some kind of depth limit Again, if you remember While I was working off of a simple tic-tac-toe board if you're dealing with a situation You know a game or a search that is much deeper connect for connect chess Checkers you're gonna have way too many potential moves And so it is going to be Beneficial to work off of some kind of depth limit my recommendation, you know, I would set Initial depth level To something like maybe Five and build from there if you end up losing, you know increase it if you you know crash because of Stack overflows decrease it But either way the next little portion here is specifically a static eval method that They sort of leave open-ended and I also in my assignment. I'm leaving it open-ended. The notion is How good Is this node Because remember right now what we're saying is We're sort of treating this like it's a terminal state Even though it's not and so we're saying okay. Well what you know Can you give me a heuristic of how well we're doing and so this is where you know Oh, you know, we talked about heuristics with you know a star search the same thing is going on here You need to give me some kind of heuristic that says whether or not this is a good state For example, one of the assignments that I've presented to my students is connect for Well connect for Just to draw that out a little bit. I think that's right Connect for you could think that And I won't change colors. I'll just use X's and O's for for this You know, if I dropped a position one more column If I dropped a position Here and then you know the other player drop their position. I drop one here. They drop one here I drop one here They drop one here. So at least in this sake, right? Is this a good move like is this column good or is this calm better? And you know one heuristic that you could work off of is how many of your nodes are connected together now in this sense Both of those are still gonna be good possible rounds, but you could expand on that, you know How many connect threes do I have how many connect twos do I have and then try and build out some kind of waiting system? So connect threes are better if I have connect threes or vice versa either way This is up to you to build on your own end and explore and play with But then we also have our terminal states. So our terminal states terminal states Here what we're looking at is again, we're going to see if any potential child This is sort of what are all my possible children and then Really this goes down to here If I have no more children. Oh, well, what are we looking at? Well, the first thing we're dealing with here is what if we're at the very beginning and so at this state initial eyes initial eyes best Move Now not really initial eyes more like Reset initial move one of the things I would recommend is you could create some type of class variable for best Move right and as you do your search that changes along the way that might work out that way But again, you notice it's doing that same kind of thing of a static eval Well, that heuristic is also coming into play even though we're at a leaf node and you can actually evaluate the actual value Again, this is just your method of oh well since we're at a leaf Is this a good leaf? Is this a bad leaf? Okay, so then we're dealing with this is where that resetting of our Best move also happens. So again if I'm at the Root node. So again, if I'm looking at that connect for game, right? What I'm essentially saying is Is this node? Equal to root is it this blank slate again just to help out my students dealing with connect for Again, if I have a blank board and I know Just not right in connect for I think I have too many columns this time Right is My node the current node that I'm evaluating equal to a blank Board now specifically I'm actually going to erase this notion of it being blank Because what happens when I'm doing the search at this state? All right. Well again, it's is it equal to what the board currently is the current board is Actually a better notion of what we're looking at here because again, we're starting off at the very beginning So we're just going to go ahead and say What is the first move? Now specifically this is where Swarthmore and my assignment and your assignment may differ Because they're using this word operator. Well, they're they're doing some weird I think it was a Hawaiian checkers. And so operators not really the best sort of notion for this best action of The first child the best move if I was dealing with connect for again that would be our column If I was dealing with chess, it would be again. What piece of my moving if it's checkers It's what piece am I moving etc either way again? If there's no other options, then we'll just go ahead and return null none Whatever but the big thing here is again. We're setting up best move and because of that We now have sort of our notion of oh, well, this is going to at least be my best move If I just took the leftmost path every single time, okay Then now we're starting to get into minning and maxing now You need to track whose turn it is and there are a number of different ways you could do that You may have maybe some class variable of turn Right and that controls if it's max's turn or men is turn and one of the things that you'd need to do is sort of when you Drop down you you maybe flip Turn is now equal to the negation of turn again That's mostly if we're thinking about this from just like a back-and-forth to player game But that's sort of again tracking whose turn it is Either way you can see that what we're doing here is again if we are in a max move So we are in max move Then we have to get all of our potential children. What are all the possible moves that I could make in my board right now? so what are All the possible moves right Now And specifically again the notion what we're looking at is what if I'm planning this is sort of my actual state So actual Board then what happens if I've been planning occasionally? I've made a few moves. I'm here then here. This is my perceived State So we're looking at when we're thinking about children is when we think about right now we're looking at this from Perception if I'm at this perceived state. What are all my possible moves? But then you can see we do some alpha beta mini maxing now one thing I have made as a suggestion sort of when we deal with our depth limit is it may be Helpful to actually just have depth be right here You know just expand on their pseudo code and track depth along the way Then as you come over to make a call instead of this being Let me actually use a I Will Whiten that out instead of this being where are you? There you are Instead of that being the end of my my method call right What if I came in and said oh well now depth is Is going plus one and then you can see oh well I'd be tracking depth as I go down my moves either way again when we hit recursive or we hit those terminal states We're doing returns of static evals. We're returning some kind of int or Double or floating point numbers so Again, that's the only thing that we are returning in the search not in the best move. That's something else So again as we're going through this we get some kind of value and If that value turns out to be better than alpha because again alpha is tracking our max We want to maximize alpha when we're in a max node then we update alpha and notice again What we're looking at here is this notion of what the best move happens to be once again operator is action What is the action that you need to take because we probably want to record you know record that and Finally, you notice one of the things we're doing is the pruning method So if we see that we have run into a situation where alpha turns out to be Larger than beta stop right that's something and we don't need to search anymore We're already done and then we do the same thing For men's turn. So same kind of thing again if you're tracking turn If turn, I don't know equals negative one then Congratulations, you now know you're in a min turn. You're still doing the same perception so moves at Perceived State and you're still doing alpha beta mini maxing you're still doing the you know depth Plus one here so all that's still happening notice again We're still tracking rather than if alpha is a result is greater than alpha We're looking if it's smaller than beta if that is the case we can change it In same thing this may still also be the best move that we can get you know Again, this is more in that sense of we do have to evaluate that because it may be the best We can get out of our situation, but then we're still in that same alpha Greater than or equal to beta approach here and then once again as you can see We would be returning beta in our sort of traversal of our tree So you'd go through and back and forth of these different Situations and so again the big things that I see from sort of students is Where am I tracking these different things? again, I Recommend that best move If you have a class make it a class Variable an update as you need Then same kind of thing when we're dealing with depth use depth as Another parameter Now again depending on your instructor and how your course is designed out you may not be allowed to but again if that's the case What do you know make it a class variable as well, and so you again keep working through this The bigger things I see a lot of times is this notion of perceived states And so one of the things you will need to do is you will need to sort of create a copy of Whatever your current state is so to make a perceived state to Make a Perceived state make a copy of your Current state Again because of that think current state also with the perception because again The actual board may just look like this again just the blank tic-tac-toe board It may work off of that, but if I create a duplication of that I can work off of that I could drop a piece I could you know place a piece again just how you're thinking about your moves and Then that would allow me to make Again because I have a cloned copy of the current state. I have a perceived I can manipulate the perceived and I can do Static e-vowels on the perceived State so hopefully this again works through this the link for the Swarthmore college pseudo code will be in the description I don't control Swarthmore. So hopefully it stays But again, this is my sort of if you want to start tackling alphabeta mini-backing Try to work through these steps and this might help again Build things out for you and plan things out and you may feel froggy and do things like negamax or something else along the way But with that Whatever your assignment is, you know do a do the YouTube thing of leave a comment in the In the comments down below. Tell me what you had to do In your class to do alphabeta pruning that way I can duplicate it and copy it and make it for my students


Welcome to JSA TV and JSA podcast, the newsroom for telecom and data center professionals. I'm Jean-Marc Lim and joining me today from London is Luisa Gregory, Vice President of Culture, Change and Diversity at Coal Technology Services. Luisa, welcome to JSA, how are you doing? How's the last 18 months treated you? Oh, well, first of all, thank you for inviting me to be part of this and great today, although it is a bit of a gray day here in London, but yeah, the last 18 months have been as challenging for me as they have been for everybody, but looking forward to restrictions really easing up. Yeah, and I guess the weather in London, I mean, what's a day in London without a bit of a gray sky? True. But look, let's jump right in. In terms of diversity and inclusion, how would you define diversity in the corporate world today? And what would you say are the main challenges that still affect our industry? Yeah, so two questions really in that. And I think for us at Colt, we think about diversity as not just diversity of types of people, which obviously it is, but what we're really aiming to achieve by bringing in diverse talent, including more women, more people from different ethnic backgrounds or even people who have both visible and invisible disabilities, LGBTQ plus. But it's really about bringing in that diversity of thought and innovation and creativity to the organization. And there's lots of research and studies that show that if you are an homogenous team, then you won't be as productive, you won't be as innovative. And at Colt, we've definitely seen some of that or a global organization. We operate across 23 different countries and we definitely get the benefit of diversity of thought based on just that. So if we can increase it even more, then that's really only a good thing for our organization. But I think in terms of the challenges, it's still a business imperative. And I think more and more organizations, particularly in our sector, are starting to recognize that. But there's still a long way, excuse me, a long way to go. So we know from a study done by entity data in just February of this year that women make up an average of 35% of the workforce of the five leading telco companies in the UK. So it's still a reasonably low percentage given that women make up at least 50% of the normal population. We also know, and this is one of the things that we've talked about quite a lot at Colt is that because of the age of our sector and we've tended to have people who come in and join this exciting new startup sector called telecommunications. And they've stuck with it, but they're now reaching retirement age. So we have a bit of a retirement cliff approaching as well. So the challenge is really to bring in that young diverse talent. They want that social mobility. They want to see organizations that are focused on changing the world, that are focused on winning together and doing things a different way or a better way. And so we just need to be more diverse in order to attract that new talent. Yeah, get the millennials and then the generation Z through the door, which value different things that the older generations did before. I mean, I really liked the thought around diversity of thinking and bringing different aspects to detail. Because I guess over the years, at least in my six years as a journalist when we started talking about diversity was very much about we need more women. No one really talked about the other verticals of diversity. I don't know if we can call them verticals, but I hope that's not. We call them pillars, so. The pillars, yes. The different pillars of diversity. So I think that's a very good point. And do you think the market is still kind of held back a little bit by the thinking that diversity, it's pretty much exclusively about bringing more women into the telecom space rather than this wider pool of talent that we have across a wider pillar spectrum. Yeah, well, certainly not for cult.  And I think what I'm seeing is the more and more the industry bodies that support this sector. So groups like the global, groups like the Global Leaders Forum as part of capacity and groups like the TM Forum, they are, they have been focused on bringing more women in because it's an easy place to start. It's a, you know, it's often a binary decision.  It's more of an obvious distinction. But more and more, particularly in those sort of industry groups where they bring the sector together, there are a lot more conversations around neurodiversity, around race, around how we bring more people from ethnic, minorities in, and, you know, clearly the whole murder of George Floyd last year changed the conversation landscape when it comes to conversations around race. I know the GLF is just about to release their, annual report on the status of diversity, inclusion and belonging and will include race for the first time this year. So I think the industry is changing and it is recognised that we need to be more inclusive around diversity types than just women. But these things obviously don't change overnight either. No, it takes time, generational. But actually, I mean, you've already, you've said it takes time. You've mentioned George Floyd. My next question was really around how has the last 18 months changed the conversation around inclusivity and diversity in this sector? Because I mean, of course, we had George Floyd's last summer, which was sad, but he triggered hopefully some good change on the back of it. We have, I mean, we're still dealing with COVID, can't get away from it. There's been some reports where they do say that COVID kind of takes away some of the opportunities for the minorities and even women and everything. And then in the UK, we've dealt with Brexit, which also impacted Europe. I mean, the world has been turned upside down over the last 18 months for the good and the bad. But how has it kind of affected the topic that we're discussing today? Well, I think it's increased the engagement on the topic. And the way that I like to think about the last 18 months is we started with this health crisis where people were losing loved ones and family and friends. And it was very much a health crisis that led to an economic crisis where people were losing jobs or they're going on furlough, having to live on reduced income or there was the threat of unemployment looming in the future. Overlaid with, as we've already said, the murder of George Floyd, which precipitated this social crisis that many people experienced, particularly our black colleagues and people of color. And all of that's led to this whole well-being crisis where there's been a lot more focus on mental health and how do people cope with things like, even the word lockdown, we use words like that, which is previously we would only have ever heard it for somebody who was physically in jail. They go into lockdown. We don't use those as part of our common vocabulary. So all of these things have really forced us to think differently about how we bring people to the table and how we include more people. And yes, sadly, there are some implications. We know that women are more affected by job loss through COVID. So those companies that have had to downscale, statistically, they've let go of more women than they have men. We know that there are some people with certain disabilities who've been more affected by not being in the workplace because the tools and the equipment and the accommodations that they need can't be easily supported in a home environment. There are others who have thrived. There are others who, without that commute, the world of work is more accessible to them as well. So there are pros and cons. And I think we just need to be really thoughtful about how we continue to think about those different diverse groups and make sure that there are no real losers. We personally haven't seen a lot as a result of Brexit. I don't think Brexit has really played into our thinking because we were always a global organization anyway. But certainly the other things, COVID, working from home, all of those things have had an impact that we've had to consider. We'll be interested once COVID is over as well to maybe see a study, a market study where we can see who was let go or what kind of position they were also in because a lot of it might actually be down to, to our old conversation around generational opportunities where women might not be in positions of power at the moment and then people at the lower end will probably get the job faster than people at the top. So maybe in the next pandemic, a hundred years time down the line hopefully, we'll kind of see this a bit more balanced in terms of who's let go. But I mean, you've already mentioned a little bit of cold as well. And I wanted to learn more what kind of initiatives do you have in place within the company itself to embrace diversity and inclusivity more. I see a lot of things on LinkedIn sometimes popping out popping here and there. So talk us through what you do, including with children as well because I think that's quite interesting. Yeah. And for Colt, this whole journey into inclusion and diversity for us wasn't as a result of, I mean, I know it's become very talked about in sort of the last 18 months. But we were on that train before that. So some of our programs are really embedded, but we do know we've also got a long way to go. So if we sort of start at the top, we've got a 50-50 gender split at our executive leadership level. And inclusion and diversity as we call it makes up one of our strategic priorities at that executive leadership and board level. So all of the sort of foundations for our brand, for our strategy, for all of that sort of one of those pillars is being more inclusive and diverse. But in the last year, we've done things like join the valuable 500, which is a commitment to supporting people with disability, both visible and invisible. We've enabled an accessibility tool on all of our websites and public spaces called Recite Me, which enables people to change the colour. It can even speak to you. You can translate it into other languages, all sorts of tools there. We have, sorry, four employee networks to support our employees with more resources around that, including one for disability awareness network. We host lots of events. We've made lots of policy improvements. So just in the last year, we've launched policies around domestic abuse support, transitioning at work, mental health support and a couple of others in there as well. Because what we believe is that having those support policies in place is really the foundation for having more conversations around these things, but also signposting to people what help is available. And we've got more coming where, actually, I think this week, we just launched our menopause at work or menopause support resource toolkit as well, because again, it's something that impacts a large percentage of the population. So we need to make sure that we're resourced appropriately for that as well. So lots and lots of things. We've trained our managers on inspiring inclusion. We held a diversity day last year. But I think that at Colt, we're really, really fortunate that we've got a CEO that believes absolutely passionately in this topic and talks very publicly about the need for it as well. So, yeah, lots of things. I mean, like as what you've done there, you kind of expanded the word inclusivity to much more. Because I guess out there, there's still a lot of companies that think inclusivity is about just employing one or two women here and then another person from a different background. So for them, it's very much a tick box exercise. While you guys are actually doing things differently and you are educating the other parts of the business as well about the minorities' issues and the problems that other people face so they can actually work together as members of staff. And I love the idea of translating within the company's platform. I never thought of that. Never thought of that. But it's one of those simple things that actually makes it all much more inclusive. Because if I speak to you in a different language and you don't understand what I'm saying, then we're both not being inclusive because we don't understand what we're saying. So actually offering that to the employees, I think that's really good. But now talking about you, because you haven't been the vice president for culture change. Sorry, I got that wrong, did I? Culture change and diversity for too long. I think it's been six, eight months. What have you learned since you took to the role? So I guess just to clarify that formally, but I've been working for Colton this space for I guess a little while. We've just kind of formalized it since January. But I think we've learned lots of things and this is a space where you never stopped learning in my opinion. So one of the big things that we kind of already knew, but I think that we've definitely highlighted is there really is no silver bullet for being more inclusive and more diverse. And the other thing I think is that it's really, really important to have strategic ambition or intent behind those plans in order to gain business buying because otherwise it just becomes another HR initiative or another pet project of the CEO. And that's when you end up with those tick box exercises that you talked about before. But if you've got some real strategic intent behind it and you can demonstrate the business benefits of being more inclusive and diverse, then you're more likely to get the right people within the organization behind it. So the other thing that we've learned is that you have to get the foundations right. I talked before about policies and support structures. And to be honest, that's not my favorite thing to do. I'm not a policy writer. It's not my favorite thing to sit there and write policies to support the organization. I'm much more excited about programs and building capability. But it's really important to have those policies in place first because without them, you just won't create that environment for people to feel like they can be themselves and really thrive in the organization. It sets the foundations and for some people, if not all, it really, they need to see those things done as well to kind of see they are taking these serious. So I think that's important. And Louisa, if people want to learn more about cold culture and the activities you're doing and the initiatives you've got in place and what's coming next as well, where could people go to find out more? You can go to a few places. We have a lot of information on our website. So Colt.net is the place to go. We have a whole section on inclusion and diversity. And maybe if I can just clarify, I know the common term is DNI or DEI. We purposely start with inclusion because we believe that building an inclusive environment leads to greater diversity. So if you go to Colt.net, you can find a whole page. We've got some great things on there. We talk about our policies. We talk about our networks. We talk about there's some blogs on there. I'm really proud of the fact that we've got our own podcast called The Full Picture, where we give our people a platform and a voice to speak about their own personal stories when it comes to diversity. We've got a Humans of Colt series, again, giving them a platform to talk about that as well. But there's loads of resources on our website. And LinkedIn, as you mentioned earlier, we do quite a lot of resource on there as well. Okay, well, I'm looking forward to see where you guys come up next. And I really like the idea of the translation within the company's platforms. I know it's something so simple and you've said so many great things, but that's the one that really stands for me. Yeah, and it's all, it's fully automated. You just, you literally, and it's on colt.net, so you can go on to colt.net and it's called Recite Me, up the top, or excessive, no, sorry, it's not called Recite Me. It's called Accessibility. You just click on that because you're all the options about what you can do. You can change the background color. Some people can't do white screens. You can change it to dark. You can change the font color. Yeah, there's hundreds of languages on there as well. So yeah, I'm sure a lot of corporations will have to copy that because it's one of those you really have to. Well, Recite Me is the tool. We didn't build it. We bought it, so. I know, but they'll have to copy this. A little prize for Recite Me then. Okay, Louisa, well, thank you so much for talking to us and sharing the experiences at colt. And thank you, our viewers as well, for tuning into JSA TV and JSA Podcast. And don't forget to check our social media channels for more content. Until next time, happy networking.


heat waves. They wreak havoc on our planet, causing fires, agricultural loss, and suffering for hundreds of thousands of lives. We can study these heat waves with a field related to climate modeling called reanalysis. In essence, when a climate model is run, it's initialized with observation data beginning in 1980, and then adjusted to new observations every six hours from that date. When the reanalysis completes, it is filled in the sparse observational record to produce a global gridded data set that represents the climate. Using the reanalysis, we investigate in detail the frequency and intensity of heat waves in the recent past. This allows us to enhance the models, which improves our ability to predict future trends. In this exposition, we'll be using the latest data from NASA's modern air reanalysis for research and applications, also known as MARA II, where we will examine the June, July, and August heat waves from 1980 to 2014 as they occurred in the Northern Hemisphere. This plot displays a 35-year span and illustrates how much warmer or colder the temperature was in each month than the average, from 1980 to 2014. This is called the Departure from the Mean, or Anomaly. Here we can see a shift to a pattern of warmer temperatures and extremes. This pattern was also noted in a recent paper by NASA scientists in 2014. However, this plot still doesn't tell us which locations on the planet the temperatures were above or below average. Using a new three-dimensional visualization tool developed at NASA Goddard, heat waves in the Northern Hemisphere are more easily detected. In this view, we can see the average June, July, August departure from the mean. The year being displayed is shown at the top, and as the map moves upwards, we move forward in time, warmer than average temperatures in red and colder than average temperatures in blue. The color bar shows that the temperature departure ranges from minus 5 to plus 5 Celsius, 9 degrees Fahrenheit, above and below normal. Now, if we turn on the east-west plane, we can see a slice around the earth over 35 years. As we move the plane from north to south, we see the warm temperature departures in red and cold departures in blue. As the plane moves towards the U.S.-Canadian border, we see an increase occurrence of the red color, indicating warmer than average Northern Hemisphere summer temperatures. These intense red colors indicate a heat wave. Now, if we move the z-plane slider up to coincide with the deep red colors, we can see when the heat wave occurred. For instance, in 1980, we see a heat wave in the Midwestern U.S. Later, we see the more recent 2003 European heat wave, then the fierce 2010 Russian heat wave, and finally the 2011 Texas heat wave. We can examine these regions in more detail. Here, we select the continental U.S. and Southern Canada. Again, as the z-plane moves through time, we see heat wave occurrences in 1980, 1988, and 2006. As we take a north-south slice and move it west to east, we see a particularly warm period. This is the 2011 Texas heat wave. This heat wave was the most intense ever recorded, and because it followed a dry winter, its effect on agriculture was exacerbated, and 1.5 million hectares burned. Similarly, if we isolate Eurasia, we can see the harsh 2003 European heat wave, where 70,000 people lost their lives. As we advance in time, we now see the very intense 2010 Russian heat wave that was responsible for crop failures, numerous fires, and 56,000 deaths. The 2010 heat wave was the most severe in this region since the year 1090. Although the three-month average shown here was on the order of 5.8 degrees Celsius above the 35-year average, there were days that were 13 degrees Celsius above normal. We've seen how this visualization tool allows us to examine the space and time extent of heat waves using a reanalysis. By advancing these tools, we are able to further explore the atmospheric mechanisms responsible for these potentially catastrophic weather events.