 Open Source project called Eclipse Che, which I'm the project lead for. Now the concept of Eclipse Che was to make it easy for us to allow anyone at any time from anywhere to contribute to a project without having to install any software. So really lowering the barrier of entry to project contribution to zero. Now this is a pretty interesting problem because today in most organizations the CI part of what we do is continuous and it is used. That's what people are doing. But on the development side, it is not continuous at all. In fact it's highly disjointed. We all run local machines. We have our own IDEs. We have our own runtimes. We grab our own dependencies and packages. There's not a lot of sharing and the sharing that's there is typically through instructions on a wiki or something else not very efficient like that. So this is a problem because you need to actually onboard developers. And this doesn't just mean when people are hired. This means at any time when you need help on your project. This could be when you're using a new API and you need to grab somebody from that API team to help guide you on how to use it best. It could be when you have a new contractor coming in. There's lots of times when you need to bring somebody into the project team kind of quickly. The double problem with this, so the reason why it bites you twice is that not only does it slow down the ability of that person to actually begin contributing code but typically the people who help somebody new get onboarded into a project are your leads. They're the experts. So the new guy isn't contributing and now the expert isn't contributing too until they've got that guy onboarded. Second problem is the classic, well it works on my machine. I don't know, why doesn't it work on yours? Yours must be a stupid machine. It shouldn't happen, right? We have the technology at this point to kill this problem if we could just let go of certain things that we haven't let go of yet. And then the last thing is that the intellectual property which is the source code which is why we as developers are valuable to our organizations is really hard to secure on a desktop. Talk to anybody in security about whether they would rather try and secure a thousand desktops or a thousand user on a central IT hosted system and they will always choose the latter. So we did a survey of several hundred developers and asked them how long does it typically take you to onboard a new developer? And you can see that by and large it was between two to five days but look at that 20% said between six working days and 13 working days. That's two weeks before somebody is actually efficient and contributing to the code. That's brutal because the code should be moving forward rapidly at all times. You want agility, you want, that's what we're doing here. We're doing agile software. We're trying to do DevOps. And yet this is problem persists. And in fact when you look at studies that have been performed nearly 25% of the time that a dev team spends is actually spent on this death by a thousand cuts of maintaining a runtime, maintaining the environment, coordinating who's got what dependencies. Am I supposed to upgrade? Am I not supposed to upgrade? What version is prod on? What version is staging on? What version am I on? All that stuff. And lastly, as I said, the desktops are difficult to secure. Now the project files in the runtime is really the IP. It's the app. It's the key. And yet that's the part that's hard to share and hard to secure. So really common solution people turn to is, well, okay, let's standardize the desktop. All my developers are going to get the same desktop. They're going to get the same image. They're going to have to use the same tools. And that really bugs developers because you want to use the tools you want to use. You want to be able to install things on your machine. If somebody goes and locks you out of root access on your own machine, what the hell are you supposed to do? Like a lot of times you need that in order to do your job. So this is not a good solution. It's also not a good solution because fundamentally it still uses the desktop. And that still has sharing control and scale limitations. And you're not solving that by standardizing it. You're just bugging everybody. So the real solution is to create a shareable and secure workspace. And that needs to be a centrally hosted workspace. That puts your IDE, your project files, and your runtime all together. And the reason why those things need to be together is because that is everything the developer needs in order to be productive, in order to actually get into the code and contribute. So I'm going to show you in a second here is Eclipse Che running on OpenShift. And the end result is the instantaneous ability to get into a code base and begin contributing. And when we've done the studies, it looks like about 30% to 40% improvement in the amount of time a team spends on these kind of tasks. So that's enough talking. Let's get back to my Chrome, to my... So this is my magic URL. This URL is essentially like a bookmark, so to speak, to a template of the environment that my project team needs in order to be useful to contribute. So if anybody new comes onto my team, whether there's somebody new to your organization or somebody just from another team, all I have to do is give them this URL. So I do that, drop that into my browser. And now what's happening is that behind the scenes on my OpenShift install, a pod is being created and populated with the operating system, the Java app server, the database, any other runtime dependencies that I need in order to actually run my app. Maven is being installed because I need that to build my app. Debuggers are being installed. Language services are being installed. SSH clients being installed. Everything that I need as a developer in order to interact with my app is being installed. Then the source code is going to get cloned into this pod and everything now can be built, edited and run. Now the last piece of the puzzle, I'm just going to make this a little bigger. People see that. Now the last piece of this puzzle is the IDE itself. In order to make this truly zero install, we actually open up the Eclipse Shea browser-based IDE. Now that doesn't mean you have to use a browser-based IDE. You can use SSHFS, for example, local mount, use your desktop IDE and just connect to the pod and use it for build and run. But the nice thing about having a browser-based ID as an option is that for folks who don't have a local IDE setup, or whose local IDE is set up to use with a different project, can still quickly code review or quickly contribute to somebody else's project. It's also great for product managers, great for docs, great for QA, folks who may not have a desktop IDE all set up for them. So here I am. You can see I've got my app right here. It's a fairly simple application. Let me just pull this down. But even so, I've got autocomplete and it's smart enough to know that I'm at the package level there and that I'm at class level here. I've got language services. I can do refactoring, move, rename. I can navigate the file structure. I can search. Let's actually look at something a little more interesting, the inherited file structure. I can jump to another class, scan through it. So all the things that I would expect of my IDE are here. So this is not just a toy. This is something I can actually use for development. I've got integration, subversion integrations. So let's go back to the greeting controller. And now let's say I want to see what this does. So I want to do a build and run. And you can see down here at the bottom, this is now the command that was sent into the pod that has everything that I need in it. You can see that it's doing a Maven clean install and it's going to deploy that to Tomcat. Now this is going to take a second. And once it's done, I'm going to use that blue link right here to open up the app running inside my personal pod. Now you remember that URL at the beginning? If I'd given that to 100 people on my team, they would each get their own individual pod, but every pod is exactly the same. So there is no concern now about runs on my machine, doesn't run on your machine, because now we're all using the same pod. So my Maven build is done. Now I'm starting up the actual app server. And we are good. This may take a second more. There we go, let's zoom this in a little bit. All right, this is a super complex app. But there we go, I've got my Hello World. So that's kind of cool. And all this is running in MiniShift. So I'm going to stop this. I'm going to go and make my change. All right, this auto saves. So all I need to do now is do yet another build and run. Now what's kind of cool about that is that this particular URL, the one for my running app running in my pod, I can of course give to anybody else who has network access to that pod. Now this is kind of cool and it's a bit of a mind bend, because now I don't need to commit and push or do a pull request in order to get feedback on my code. I'm working in a local copy right now inside my pod. I can give this to my product manager and say, can you tell me all the ways in which I have failed and I need to make changes before I go and push this? And now I can do it while I'm still in the right branch, still kind of in my flow before I've gone and pushed, before I've gone and done my pull request. I don't need to redo anything. So I need to just kind of go through that. Now in a second here, we've got our startup again. I'm going to reopen this and I'm going to do a different name and there we go. Now we're super internationalized. So very basic, but very cool. So the last piece of this puzzle is let me come back to here and let me go back into my workspaces. Let me add a workspace. Now you're maybe thinking, okay, this is all a nice pre-canned kind of demo Brad, but there's actually more to it than that. There's a lot more you can do. So sure I have all these pre-canned stacks available to me and in ChaseSpeak, a stack is a combination of the various run times and dependencies that my project would need. So this is kind of everything other than my source code. Now so you can see I've got ones for Node, Wildfly, Vertex, Java, MySQL. Now this one is quite cool because this is now a multi-pod environment. So now as a developer, I actually have the ability to be dev-ing in a two-pod, three-pod, ten-pod environment all networked together. Kubernetes and OpenShift are going to make sure those things start in the right order and I can still go and edit and change code on any one of those locations. So I can be working on a complex microservices environment that is personal to me, even if it is scaled too large to fit on a laptop. Now of course, I can create any of these stacks myself just by going into Add Stacks and then I can create something totally custom with exactly the run times and the systems and components that I need for my project. Once it's done, once again, I can grab one of those magic URLs, pass it out to my friends and co-workers and bang, everybody's on the same page and everybody is doing exactly what they need. Now, if you want to give this a shot, which I would strongly recommend, you can go to the Eclipse Chay site. Now this is an Eclipse project, so this is all open source of course, all free. If you go to eclipse.org forward slash chay, you go to the main page and if you go into our docs, all right, so there's the docs. I can get started now by going down to OpenShift installation and you'll see that I can install this on MiniShift. I can install this on the full OpenShift container platform. I'm using MiniShift here because it's easier. It just runs on my laptop. I can kind of play with it there but obviously running it on the OpenShift container platform is a lot more powerful because now I can share this with my whole team. Now the one caveat is we are this close to having multi-tenancy in Chay, which is obviously a kind of critical part for doing it for my team. So in November, in just a few scant weeks, we'll be releasing a version of Chay with full multi-tenancy using Key Cloak, which gets you OAuth and LDAP, for example, authentication, running in OpenShift container platform or MiniShift. So at that point now I have everything I need to have a fully horizontally or vertically scalable set of developer workspaces for my team tied into my authentication all nice and clean. Really can change the way you work as a development team. In the meantime, if you're interested, I would strongly suggest coming, trying the OpenShift installation on MiniShift, try it on your laptop and just kind of play with it. It's a pretty cool tool. Obviously I'm a little bit biased as the project lead but nonetheless, those I was saying today we've got the single user on OpenShift which is great for a MiniShift install. Going forward, we're going to have multi-user which is perfect for the larger OpenShift container platform. Now the last piece of the puzzle is that Chay is also being integrated into the set of end-to-end developer tooling which is used by OpenShift. We're calling it OpenShift.io. And if you're interested, you can do a workshop here in 15 minutes or later today or tomorrow, where you can actually play with building a brand new project in Java, editing it, building it, rebuilding it, staging it and deploying it in OpenShift. It's actually a lot of fun but it really covers all the elements that you need as a whole team. Everything from work item tracking through the editor, through Jenkins, through deployment. All right, that does it for me. Thank you very much. If you guys have any questions, I'll be hanging out here for a bit. Otherwise, please do join us for our workshop. Thank you.