 So, yeah, first of all, it's great to be at the first Eclipse Summit. It's an honor, actually. That's Praveen and I am Pradeepto, and we will be presenting one part of the story, and we'll be elaborating on that in the next few slides. So, before that, a very, very quick introduction to who we are, exactly. We both are engineers in Red Hat. We are part of a group that is called the Developer Tools Engineering. Our sole mandate, as we understand it, is to make lives of developers easier. So, when you make software, you make it for somebody. You make it for a bank. You make it for, I don't know, whatever, a rocket, or I don't know, some space agency maybe. But we make it for you guys, the developers. So, as I said, we will be working, we will be talking and elaborating on a particular side of the story. You will see that. So, what do we do, what do I mean when I say Developer Tools? It could be anything. It could be your Eclipse IDE, of course. It could be your Container Tools. I am pretty sure everybody probably have heard, if not used, by now something called as Dockup and Linux Containers, right? And that's one of the very important tooling that you need in the world of today. And so, and how do we use it and so and so forth? There are a bunch of ways to do it and so and so forth. And when you have those tools, you need to orchestrate them. You need tooling around it. So, our team basically works around this kind of things. And which I consider to be a really good thing, and I'm sure Praveen does in some of us. We have some colleagues here as well. I know Praveen from almost a decade now. We have been in the open source world for some time. And we know, we really feel very passionate about and Eclipse itself is an open source project, right? So, everything that we do, our team does, the RHD does, is basically an open source. So, that's a very quick introduction. We would love to talk to you if you come and talk to us outside. No input detected. Okay, yeah, that's fine. So, I have a question. How many of you are developers? I'm sure, I mean this question is a bit loaded, but I mean, who are not from IT or operations? Can you raise your hand maybe? Okay, so rest of you are from ops, like people who do DevOps, or you are developers as well. I can see yes to everything. So, can you please tell me? I mean, you know what it is. So, are you from developer side or are you from the IT or an ops side? Developers, excellent. So, that's what I wanted to come to. And I hope you attended Fred's talk yesterday. He talked about how he takes some code from Eclipse and deploys it at that point. We are concentrating on the developing part and when you are developing on your local machine, that's the developer story we are talking about. So, I as a developer, what do I want? I want to write code, first of all, obviously. I want my code to be basically, I want my editor and in this case, Eclipse. I have used CDT of Eclipse because I was a C++ programmer in my past life. So, I want to start my editor and start writing code, literally code away. But that's probably worst possible few years ago, maybe I don't know, but then I started doing things like Ruby, Python and whatnot. When I do those things, I need to install, it's not that I didn't have to do the similar things in C++, but you need your dependencies, you need your stack to be right, you need your, if you're doing Java, you need your Maven, you need your Ant, you need your Gradle or whatever it is. If you're doing Ruby, you need your Gems to be correctly installed. If you're doing Python, you need your Python Modules to be installed. Maybe you need a version control manager like Virtual Land on something like that. When you need all those things, you have this downtime of setting up. People have been trying to automate it with various tools, build tools around it and so on and so forth. I don't know about you, but I know this guy from, as I said, from 10 years. He's a super awesome engineer. Every time I meet him, he wants the spec and then he wants to write code away. He really does not want to waste time in setting up everything. I am sure you guys have faced that. You have to install this and that and everything else, especially if you are doing stuff around web services, if you are doing stuff around microservices nowadays, as they are called, and then scale them, you have to think about so many things and so on and so forth. But when you have all those things, it's not your machine, right? The code is going to run. It's probably going to be run on somebody else's machine, basically production. Isn't that true? But before going to production, probably you will be running it on test machines, correct? And there will be some people who will be writing automation QA. There will be some people who will be doing manual testing. Not some people, some Jenkins machine might be doing the automation QA, of course, but maybe there are some people who some projects need manual QA and so on and so forth. But you need that testing environment. In some companies and some projects, you need a staging environment as well. You see, I'm talking about your same code, the poor same code that you wrote has to travel. And people have been trying to make this life better. I'm sure you have heard of things like continuous integration, continuous delivery, continuous deploy, right? So people have been trying to build tools, build workflows so that this makes it easier. But can you control everything as a developer? I'm the simple developer. I'm talking about myself. When I write the code, I have few things there. Then as a developer, I know that I always want the super shiny new latest library, right? Talk to your IT person or your ops person, he will hate you for that. He wants, he or she wants the most stable REL machine or a CentOS machine or something else or he or she wants the security audited bundler gems from Ruby or Python modules or Java modules or whatever, some version of Maven which may or may not match. And you have to deal with that and you have to live with it. It is a fact, nothing can change about it. But then you have to set up your machine like that, right? In today's world, how many of you have worked with containers maybe? Linux container Docker, some of you maybe? Yeah, I see a few hands. That's fine. So if you have heard about it, at least read some blogs about it, it helps your workflow. It doesn't matter what stack you're using. As a Eclipse programmer, there's a high chance that there are Java programmers here. But really it doesn't matter after beyond a certain point. If you're using localized container development, your environment that you need are basically localized to that container image which is running your stack and you can run your code over it and whatnot, right? But even that requires learning technologies like Docker command line or Linux container internals and whatnot. Maybe not container internals, but at least the command line to understand them how those are built, how they work, how they store files, how they do networking and so on so forth, various things. Especially if you are writing multiple services, let's say you are writing multiple Java web services and this service needs to talk to that service and ideally you need isolation and you keep one service running in one VM, let's say for now and the other service running in one other VM. So VMs are kind of going out of the trading against containers. So you do it in a container, in a different container. So you need to orchestrate them. This kind of setting up period is what I'm talking about. The downtime of setting up, right? But what do I want to do as a developer? This is what I want to do. And we have been building tools around it and Praveen is one author of one of the tools that he will be talking about. I give it to him from here. So let's consider how many folks you can, we have an application, but we are assuming that your ID folks, which is already audited for them, right? Which have all the required lines, right? And then talk of that, we start writing this. So that when you actually send it to the forex or in the stage area, you will not face that kind of issue that's just being running in my computer and it is not running in there. I mean, or maybe some library is better, but that's right. So what we have is, we have an atomic developer bundle, but actually this bundle is, it's a background box. How many folks know about the background here? Awesome. So we have a background box, which we actually provide, so that the background box is provides for two different providers. You can run that background box on the windows. You just have to download that background box. You have to have one background file which is right, and then just you have to do one background up some more. And it will set up local, running local inside the box for you guys. And then we also provide tools around that particular background so that it will make sure that we are here to interact with that particular box. So that what we are going to do. So when you said Vagrant, I saw some hands that were not up, that's fine. So I'm sure you have heard of virtual box instead of that, right? So Vagrant is just one layer on that. It's basically a domain specific language that you can use. So instead of taking the virtual box UI and creating an image, and then or rather taking an image and starting a VM with it, you can write like literally three, I think the bare minimum is to write three lines of Ruby code, and that also you don't need to write. If you say Vagrant in it, you get a boilerplate code when you say Vagrant up. After that, your VM is up, and you can configure your VM within that script like nothing else. You don't have to test the UI at all. So basically you can program, automate the hell out of it. So these are the things that you will see for the demo. If you see here, when I did Vagrant box, you can see here, the provider is after that, the box which I have in this one, and this is also available in the, and after that it's just, once you have that ready, then you have the local which is running inside the box. It's, so if you want to connect from the box, right? What are the signage? It's difficult, you have to read it out. So once you actually, what are the pop-up window? There's a magnifier, do you know how to trigger the magnifier? So this, what it will ask is that the TCP connection. So I'll just put the TCP connection, Vagrant service manager. Now, a project structure, when you are actually using the container technologies, is that you're supposed to have a Vagrant file, so that you can create an image out of it. So if you see here, which is hell over, you are there, right? Right now, this is the LAN, LAN we are going to add it in the LAN. And you can see, we are using a base image, which actually the base image is divided by our IP. We are assuming that, right? So somebody is giving us the base image, which has proper library for already over the entire team. And after that, we are just putting it on. This is like a glorified script, that's about it. It just says that, that image is the image that you need to use. And that's what I was talking about, that image or a golden image from some operations person you have it, you just tag it there. Your company or organization is in continuous delivery or integration method. Maybe they are also going to use the same image to build the port on top of it for your, whatever the port is you do, and then tag it with the, and run the dash. So now what I will do is that, if I have the docker file, I already have a connection for it. If I just say here, I will go here, and then I will say run. But I have to build that image. I already have to build that image. It is just system image. So the image is here now, which is already there, which is my app. I already have the version. You can see the version information here. This is what's the version. Now I build the image now, without leaving the fields, you can even start that image, and then the application is running or not. So if I say run, it will again open a pop-up window, which will ask that if you need any entry points to meet arguments for this part of the command, you can give it. If you want to change the port, which I am going to use in the 80s. So once it's everything, then I will say finish, and it will start running the image. So the now image is running. I want to access my application, so what I will do, I will go to the browser. Which way normally does it work? Good, right? That I send some, you can see the request gate and say, what if I just put a URL, which is not actually the endpoint. It's very simple, again, change the... The thing that the most value-added thing that you have to realize is, you did not, he did not install Python, he did not install Django. So yeah, I know this is the Eclipse conference and most of you guys are Java. So you wouldn't have installed maybe Maven, and maybe you need JDK9, or maybe JDK8 point, whatever. So unfortunately, I'm not a Java guy, but I'm just saying you don't have to install those. You have a pre-built image. All you started was with the code, and there was some image that somebody provided. And in all likelihood, the proper images or images that the community is building, and uploading to whichever registry you are using, are already there. You don't need to do anything, but write that Dockerfile with the right name, and write your own code, and he has the running code. So you can run build test, rather code build test, your code all the time. And at the end of it, your code when it's just shipped, we have assumed one thing. Whenever you write a program or you create a program, there are some assumptions that need to be made, right? The assumption here was we have a golden image, and it is often so, to be honest, right? The stack is pre-decided by whoever in the company, by maybe by cumulative decision, or maybe by a dictator who runs the company, right, or the project, right? So those things, once it is done, all you have to do is only as a developer, you don't really want to break your head with dependency here. That's the whole point. If you go step by step. Yeah, you will be able to do everything that Praveen did by going to the last link, and we have uploaded the slide already. Yeah. So one question from my side, Praveen, can you show the Vagrant file? I want to show, tell them that how easy it is. It might be verbose, but it is really easy. So just in case, he did a Vagrant, well, we didn't do it ourselves here because we kept the VM running, but this is the file, Vagrant file. It looks, it cryptic, but it is pure Ruby. And anybody who has seen Ruby ever will realize that Ruby is very English-y, right? You have things like unless and whatnot, do, end, and things like that. So all he does is he configures the VM, and that also you really don't need to, we are providing, frankly. All you have to do is Vagrant up. And the best part is, if you're doing it using Windows or Linux, all you need to install is the virtual box, which in all likelihood you have it, Vagrant, and then the box that we are telling. The box is nothing but a, let's call it an image for now, right? It's basically a packaged image. Yep, you're saying something. But let's show it to them. I think they will understand anyway. So we are setting up network and all that. You don't need to do this, but this is there. Yeah, the most basic one is literally three lines. And this is the whole plumbing work or the background work that we have already given to you when you are using Atomic Developer, but. Cool. You will find all the information in the last website. Cool, thank you so much.