 It's a nice opportunity for people from the government. So, me and Anand Prakash, we both are track captains for the devos that will be with you today. It's the first of improving developer experience on OpenShift. He is from Spain and he is a developer advocate of OpenShift. He is going to present a cool project. I will try to talk to the mic so I can talk to the other guys. Hi, my name is Mokhen. As I said, I come from Spain. I am not native English speaker. English is not good, but I will try to do my best. Today I am talking to you about improving developer experience on OpenShift. OpenShift is going to be done in three parts. This is going to consist of three different acts. The first one is how, whenever we talk about improving developer experience on OpenShift, what is this OpenShift? Do you guys know what is OpenShift? You will come here to understand and to learn how to improve developer experience on OpenShift. I guess you know, but I might do a little bit of an introduction to what is OpenShift on OpenShift. So, Kubernetes, it is a cool project. But there are a lot of people that say that Kubernetes is many different things. If you look into this stream, there are people saying that Kubernetes is a new kernel. There are some other people saying that Kubernetes is a new application server. So different ways of seeing Kubernetes. But if you look into the official documentation, what they say and Google themselves, Kubernetes is just a container orchestration platform. So it just launches, manages your containers. So then what is OpenShift? OpenShift is a cool project that extends Kubernetes to make the life of developers easier. OpenShift is a Kubernetes platform for developers. Why? Because it doesn't extend Kubernetes with some developer tooling that helps you on the application delivery, life cycle of your applications. So it helps you create applications. It helps you manage your application from development to production through the features of continuous integration. Continuous integration pipelines, through a set of building capabilities, through, it helps you whatever your developing application with centralized logging, centralized featuring for your applications. So it gives you developer view and developer friendly via your application. Okay, that's OpenShift, that's correct. So the second part is from whatever we talk about improving developer experiences, what is developer experience? What we talk about developer experience, what do we mean by developer experience? So developer experience is just user experience, but when the user is a developer, so we need to make a distinction, or there is a distinction between user experience and developer experience, although it shouldn't be a distinction, because at the end of the day a developer is just a regular user. But the problem is that we often see that when the user is a developer, we are not so focused on making things more usable or easy to use, they just need to work. Why? Because we understand, we think that developers, they are skilled enough to just cope with the bad experience. They don't care about the experience as long as things work. Doesn't need to look great, they just need to work. This is wrong. Developer experience, we also care about the experience, we also care about doing things the right way. So this is one thing we constantly see, user experience. We think about the end user that we need to make things fancy, looking awesome, easy to use, and when we think about developer experience, we want it to be successful. When we look into developer experience, it's not so important to make it nice, we don't put so much focus or emphasis into the design, we just put some focus on things that need to work and needs to get your job done. So this is how the user would be versus a developer, how he would feel when using a product. So developers, we are, I guess most of you, all of us, we are developers. We want to have a lot of choice. We want to be able to select the languages, we want to use them when we create our application, we want to be able to select the runtime, the database, anything. The tools that we use when we create our applications. I might like something I believe in, intelligent, or I might like an Eclipse IDE. I want to use my tools, the things that I'm used to when I'm working on creating applications. I also want to be at the same time, so this is one of the key goals that we need to think about when we're talking about developer experience, productiveness. So we want tools to be stable, not to change whatever it is. We want to have every function that we need in our hand, and we also want it to be intuitive. We want our tools to not require a steep learning curve just to be able to use them. We want the tools that we are imposed to use for our platform, for example, like an offensive, to be easy to use, intuitive. So why developer experience matters at the end for developers, because users that use a good developer experience. At the end, they are happy users, and they promote their technology. They say, hey, I've been using this cool technology, and it's so freaking easy to use, and people will start using it. Yes, why spread out more than a month? When you have enterprise-grade products, maybe like offensive or some other and component distribution, if the developer experience doesn't shine, the problem is that it will feel pain on a daily basis. It will be developing and you will be thinking, I need to wait here a couple of minutes for things to be done. I need to learn all these new things. I don't really like this platform. I might not use it because it sucks. So we need to think that developers, where people think developer experience is very important because we just want to be treated as regular users. And the fact that there is the difference between developer experience and user experience just sucks. So we are people or many others. So developer experience, obviously, we all already know what it is. Also the things, how can we improve developer experience? One way of improving developer experience is the index. Multiple monitors. Hey, you will have a happy developer. I got so many screens to work. In fact, I have three at home and usually I am black too. Why? Because it makes you context-switch so much. It makes you distract so much. You are not productive. So this is not a way of improving developer experience. Developers, we just want to do our job. We want to focus on the things that are important and the things that matter. And what is important for us for developers? The code. We just want to code and to make it easy and efficient. And that's it. We don't want to learn new things every time we go from here to there. We just want to know Java. I don't want to learn any of these co-interestings or this Python things that I would maybe need for something. So today I am talking about a new project that we are bringing out which is called Odeon OpenShift 2. And this is a developer-friendly command line tool. Why command line? Because when we start thinking about how to bring new experience to a user, to a developer you might spend a lot of time maybe crafting a new nice experience on the web, UI or tooling, but you might get things wrong. So the easiest way to test the experience that you are creating is the proper experience for users. This is starting with a command line tool that most of the developers can use that you can also plug your tooling to these command line tools to APIs. And then if they are successful and if your users feel like they are happy with it you can extend to all the areas of different aspects of the platform. So what is Odeon? Odeon is a command line tool that is simple to use. So it doesn't really bring any new concept to you even though it's meant for you to create applications on OpenShift or co-ordinates it doesn't require you to learn all these co-ordinates of OpenShift very much. So there is a lot of things that this brings to the table like builds, deployments, routes, deployment configs and all these kind of things that are new to you. Why do you need to learn all of that? So this tool just tries not to impose new terminology on you it tries to use something that you can feel comfortable using. It's also fast and it helps you with creating your interactive development workflow. So what you are a developer on your daily work look like. I do some code, I test it I make some changes I test it again I add some functionality I may test it again and then at the end of the day when I'm done I might say hey this is ready for the whole set of my colleagues to use it so I might check the code into the central gate repository and then maybe there is a central pipeline that allows you to create your own application lifecycle properly. Also it promotes in-context work so that means that you get into the context of one specific component and we will see an example right in a minute you are working everything you do is in the context of that component why? Because this is a typical way we understand developers' use of work I do it the wrong this is a specific part of the application so you know the first thing we do is we create an application and an application is nothing more than a wrapper or a holder for all the work that you are going to be doing or creating so why? Because we understand that an application might be consisting of multiple different pieces multiple different components but an application itself you will be using in a productive system so you need to identify all of the pieces that make part of your application that is nothing more than a wrapper I want to create an application nothing really happens apart from creating this wrapper or marketing once you do that you select what type of component you are going to create and the component is the application or the specific part of the application that you are going to be creating because maybe you want to use Wildfire or Jetty or Tonka to create your web service so the component is I am going to work right now with Tonka or Wildfire so I create one of those and every time I create or I make some changes make the changes in context of that specific component so that means that from that moment everything you do it will be done so if I want to, for example create some storage or attach some storage to make more application so if my application server stops every storage I want some computation to be there on the application server so when I add storage I add it to my application server so I add it to my component I might also introduce things like creating a database adding a database to my component maybe I need to add a database so I can search into the available technologies that I have in my catalog and then once I use the specific technology that I want to use I just say hey, deploy me one of these but this is a service, this is something that I will use this is not what I am coding in this this is not, every time I do some code changes it will not go to the database, the code changes will go to my Tonka application or my Wildfire application say hey, my application might be composed of more components so I might have a frontend application from the part maybe a Node.js frontend what you want that gives me some functionality so I create from Node.js source I create any component and I say hey, this is a Node.js application everything that I do from this moment it will be in the context of this Node.js application so I can say hey, my Node.js needs to talk to my Wildfire application back so I link it what it will do is just connect it in the proper way as you see the turn that it's using is easy to use it's linked under the hood it's doing a lot of cool remittances if it will stop creating environment environments, copying my secrets what not you may want to say hey, I want to use my application, I want to make it available trade me a URL it's as simple as that of course it's something you need you can provide many different arguments to make it more flexible but by default it will give you the same that you can use whenever you are available again in the context of your application and this will be done for your application from that point once you have created a URL you can access your application through your own web browser and then once you have all of this something that is not easy to show the diagram is it's a little bit like a workflow so what I do is, when I create a component I can say hey, trade my component from local source file so I can find Java files so when I'm done with my encoding I want to push these files into the running application server the application server at that point or this time what it will do is build your Java can build your Java application internally and it will make your application available or you can say hey because I'm using Maven and I know Maven works perfectly on my laptop and I have everything on my local cache my end to the directory I might want to just do Maven package create a warf file and only push the warf file into my component so you can configure your application to use a binary file as source so when you create your component you say hey, all the old trade whatever component you want to like use this warf file and every time I do push this warf file will be pushed to the application server and the application server will be restarted the workflow that you will see is the same workflow you will follow on your laptop but it's working on all the same components and it's using containers and it's using all this cool technology and the good thing is that all those containers that you are creating will be the same that you will be able to put into production so the life cycle the application life cycle is the back end these are coming from GitHub so there is two repositories that I'm using we can go to the back end and get remote finance main and we see this is coming from the repository of one of my colleagues so right now I don't have anything I just have audio just to set the context of the project I'm working in usually when you are an open seed user you might not need to use this so why I set myself into a project is because I'm the administrator of this project and I have access to multiple projects usually when you are a developer you are using the context of one single project in open seed so you might not need to do this so once I in the context of one project the first thing we will do is create an application so audio, app, create the name of the application so we are going to create a game which is a wild wild website everything was working fine really slow and here there is an engineer for this project and probably they have a really slow timeout is there a way in that I can get faster fun this is the workload I saw you is more or less what I was going to show you here I'm going to play the engineer not suddenly I have to play him it will be my fault so audio where you can get this tool this tool is available on GitHub everything we do is open source and you can get it there the slides will be available online there is a recording that you need to understand is that designing a CLI of designing an effective CLI effective CLI design is not so easy so we are not really sure how this will play out so this is the early stage of the project we are now at the moment that we feel comfortable talking about the project it works although this sliding little problem that we have probably this is the first time we talk about this project publicly contributions as everything we do they are welcome we want to hear your feedback so if you get the URL to the URL you start using the product and the command line and if you think there is something that we can improve let us know how this will play with the workload that you will have as a regular developer using open source we think this is going to be it's going to boost your productivity a lot if you are developing applications with open source mostly because it helps you on this part that is not really something that OpenShift really provides right now which is the development cycle of your outside development whenever you want to code and test code and test this is not easy you can do it, you can still do it with OpenShift but there is a lot of commands that you need to learn there is huge command lines with a lot of flags that you need to run this makes things easier also sets OpenShift in a way and everything that works in OpenShift in a way that makes this iterative development cycle much faster so please start using it give us feedback and if you think your this is the great thing you go if you feel like you can contribute if you do not go get in contact with the team developing audience and that's all everything I have so my job done, poorly done because the demo didn't work I'm sorry for that and if you are curious about it just come later to talk to me I will try to hotspot through my mobile phone and I will try to make a live demo to any of you if you want to see it in live and please remember to visit LearnOpenShift.com if you are in the process of learning OpenShift this is a therapy portal that we have for learning OpenShift thank you for everything and if you have questions raise your hand I think you have still 5 minutes given that the demo didn't work so you are up for asking questions there is no initial setup so this is one of the things that we try to do is we don't want to impose an initial setup at the moment we might need to change our approach in the future but we want to be non-intrusive that means that if you already have an OpenShift installation just download the command line tool just use the command line tool if you are using Kubernetes instead of OpenShift you will most likely not be able to use it because it's using and at the moment it's using some OpenShift constructs we are trying to what are the differences between the constructs that we are using in OpenShift and Kubernetes because we are not using things like build configs which is OpenShift, but we are using rounds which is OpenShift whenever I did the audio create what it does is behind the scenes if you are in plain Kubernetes there is no rounds so we might look into how to make that possible in Kubernetes in the future right now this is just including the developer experience as I said at the beginning the difference between OpenShift and OpenShift is a developer friendly or oriented platform but Kubernetes is not you can develop of course in Kubernetes does it take the complete DevOps cycle does OpenShift address the complete DevOps cycle so the question was does it cover the complete DevOps life cycle and the answer is no, this is for the interactive development cycle this is for developers so how it works is I'm working locally I clone source code to my laptop I start working cruise, test, cruise, test, cruise once I'm done one of the things you say is I'm done so you say change this application and this is the git repository so from that moment what it will happen or what it should happen is that you should have a pipeline just listening or watching this git repository you have pushed the code and then a regular application build application provost on a life cycle should start usually this is how you could develop with MiniShift maybe locally or even with a cloud platform locally but it's for interactive development cycle to make this process that right now is not so easy to improve your productivity the rest of the body the question is which industry is going to impact the most I don't think it's going to impact any industry at all the only thing it's going to impact is the developers productivity so if you are developing in any type of industry it's going to improve your productivity it's going to make you able to create applications faster and more in a more comfortable way so one of the things that we are seeing right now is that many developers they tend to develop locally using the the current workflow that they have maybe testing locally not using even containers it's not easy because that's easy for them to use and going testing or developing against the platform and host the platform in coordinates of an open scene is really complex understand that the workflow is more simple so productivity is not good, the developer experience is not good what we are trying to do is improve this developer experience to make things easier to use and just to get the developers to start using or start developing against containers as soon as possible I think we are probably out of time yes yes ok thank you very much for coming if you have any questions any problem or any questions with Odo so for everyone Graham has a workshop in the evening about a workshop we can ask them but the workshop that we have today at 3 it's not about local development with ODO which we will probably do next year or whatever we feel we can do this type of workshop my demo phase just think about the full workshop and the workshop we are doing is the workshop with ODO so we are showing how to promote applications from development to promoting to production do programming with your application just pipeline and all these kind of things so if you are open city service come to see us at 3.0 thank you this is going to be about the possible project in QQ from give us a moment to say