 Hello, everybody. Thanks for coming. My name is Ilya. I work for Red Hat. I'm also part of Eclipse Foundation. I am Eclipse J and Eclipse JavaScript Development Tool Committer. I enjoy conferences and really happy to open in 2020, my 2020 speaking season here with you in Bernat. And today we are going to talk about Eclipse J, an open-source project on the Eclipse public license. It is Web ID that is designed to make container native development super easy. And before we start, I actually have a question for you. How much time do you think a developer team spends on configuration and setup on a weekly basis? Do you have any idea? So, according to the Avans Data Corporation report, 24% of teams' time is spent exactly on configuration and setup, not on coding, not on meetings, on configuration and setup. And it's a big figure. If you think about it, it's more than one day of work. Right? So, and it was not always like that, because if you think about it, what was development look like 10, 15 years ago, it was a completely different story. For example, 10, 15 years ago, it was Java apps, for example, and it was Java from front to back, from top to bottom. You had one version of GVM, one version of the application server, and that was pretty much good. But now the story is different. So, here you can see on the next slide the cloud native landscape. And if you are a cloud native developer and if you work with microservices, this is the tools and technologies you have to work on on a daily basis. And complexity of the application has changed dramatically. Also, if you think about it, our laptops are not ideally suited for this landscape, because in order to develop cloud native tools, you need sufficient amount of CPU, sufficient amount of RAM on your laptop, and it's not the case currently. So, to develop in this environment, to be comfortable with, you need laptops with, at very least 24, 32 gigs of RAM. So, and this becomes the first problem. The second thing is the onboarding process. If you read this book, this is a brilliant book about IT. It's a page turner, actually. So, it's called the Phoenix project. It's described the project which has a lot of issues. One of the issues is the onboarding. So, it's quote from the book. For Phoenix, it takes us three or four weeks for new developers to get built running on their machines. And that's actually not exaggeration. It's pretty much a situation which relatively big companies face nowadays. So, the setup and configuration is a big process nowadays, and onboarding can take weeks. So, this kind of solution for this in the book was using the virtual machines, and the book was written in late 2013. And we know that the first version of Docker and first version Kubernetes were roughly at the same time, were released roughly at the same time. So, if the book was written a little bit later, it would definitely talk about the containers and the orchestration instead of virtual machines. And those two problems, configuration and setup plus the onboarding, are the problems that we want to solve with Eclipse chair. So, as I said, Eclipse chair is the web ID, but more important, it's Kubernetes native ID for developers and teams. And the motto of the project is that anyone, anytime, can contribute to a project without actually installing software. And now I want to show you how it looks like, how it feels like to develop in a chair way. So, let's imagine it's your first day at work, and you are in a new company, and you are assigned to a new project. So, let's go to the GitHub page of this project, and we see that it is Quarkus React.js posted application. And the application is actually deployed on OpenShift. So, on OpenShift 4, there is very nice topology view, so we see it consists of three microservices. So, it's not front-end, Quarkus back-end, and MongoDB for persistent data. The application is pretty trivial, but still it consists of three microservices, and here how it looks like. So, we have an input fields. We can input the title and the content. So, let's input hello, burn on, press and submit button. And we have a post persistent and the database and reflect it on the UI. Even though it's pretty simple application, development setup might be pretty complex because you need to install Mongo, you need to install build tools, you need to run the node, run the Quarkus, get it together so that it will run smoothly. So, you could easily spend, even though you are a skilled developer, you could easily spend one day of work just for environment setup. And you are assigned to a new issue, so let's open it, it's in the GitHub, so display the title of each post in the uppercase. Pretty simple one. So, what you would normally do in the regular environment, you would, you know, install all the tools, try to set up connections between microservices and fix it, and now I will show you how we promote, what the flow we promote with Eclipschia. So, at the bottom of the issue, you can see that there is developer workspace button. And if I click on it, I will be switched to the login page, so I will be provided with the credentials for my account. And once I log in, a new environment would be created for me, with not only the source code, which is an important part, but more importantly, it would contain all the tools and all the runtimes for starting development of the application on the fly. So, let's try to open some files. We can open posts, post Java file, post resources to understand what it looks like, so we have a Quarkus controller here. We have a MongoDB running, so I can log into Mongo, take a look at what databases are there. And I can start my Quarkus backend right from clicking on one button, which defines the command for running the app. Oops, and the route exposed for the Quarkus backend, so I can see it on preview, and I can also access it through the regular browser, since its route is exposed. So, Quarkus is running, it's just a simple page. Quarkus is backend part, but it's just a sample index HTML that shows you the state of the application. So, it's just for development purposes. Now, let's run the front-end part. Also, one click, and I have all the commands running for starting the node. And on port 3000, I have a node running now. So, it's my development environment. Two clicks, two build commands, I have everything set up. Live demo and content, submit. Okay, live demo. Let's take a look at what happens in the database. I will just remove it here. Open my Mongo terminal. So, use sample DB and DB posts. Find. Okay, I see live demo title is there. All right. So, now let's try to debug it. Let me put some breakpoints in the code. So, in the issue, we need to change the title, right? So, I will put the breakpoint in the get title method, and I will run the debugging. So, I'll start the debug session right away. And let me refresh the page. Okay, and I'm in the debug view now. So, I can see all the local variables of the post. I can see information about the title. I can skip it right now. So, debugging also works fine. And I think that I've figured out what the trick is, and I need just to get title through the uppercase. You see, I have a pretty nice content assist here to uppercase. I forgot to put the brackets. So, I immediately get the error marker. I'll put it here. And I also have the nice docs in order to get information about what the uppercase is for the string method. And since it is quarkus, it's subatomic life reload is enabled by default. So, I can just refresh the page. And you see, live demo is displayed in the uppercase. So, what I need to do now is just to go to my git. So, I have a git plugin running here. I can do something like I can add the commit message here, create a branch, and push it to my remote. And if I go back to GitHub, I can send a pull request right away. So, and imagine everything was done inside the browser. So, I did all the interactions with the applications starting from the onboarding where the single click to committing from my browser. And more importantly, so the point is that if you want to develop microservices and if you develop in the cloud native landscape, you should be able not only run your apps on the Kubernetes or OpenShift. You should run all the tools and all the environment also on Kubernetes or OpenShift. So, here we have an OpenShift plugin. The last thing I want to show you is that we can log into our OpenShift cluster here. And what I can do now is I can log in from the eclipse chair to this cluster. And I can see what applications available for that user. And now if I want to, for example, spin up yet another service or yet another port, what I need to do is literally just to open a terminal. And I can do it from the UI. I can do it from common line. I can do just if I have a template for OpenShift for yet another microservice. Here is the template. I can just do OC apply. And on the topology, you can see that the new microservice is about to start. So, that's what I wanted to show you during this demo, during this live session. That first of all, first day at work could be different thing in the cloud-native environment. And we move all the complexity and all the tools to the cloud. So, we do not develop on local host anymore. So, I will just quickly touch the chair architecture. Because the important thing before we go into this detailed diagram is that we can imagine that eclipse chair consists of two parts. It's controller part, so the main part, which is called Kubernetes API, which spin-ups the workspaces, which are literally ports that consist of a couple of containers for tooling, for runtime, for testing, et cetera. So, the most important thing is that everything is running inside containers and ports. Then, going to this diagram, we can see that there is a container on the bottom. We can see container orchestrator. And the thing is that eclipse chair is cloud-native IDE that is run on top of Kubernetes or OpenShift, which is downstream project of Kubernetes. On the top, we can see browser. And it's not a surprise because all the interactions happens from the browser. And you see how fast it was. So, you even might not recognize that I developed inside the browser, not inside my, I don't know, GWT or Swink IDE, right? Then, there is a chair server part. And it's actually the controller of, you know, everything inside chair. So, it's in charge of authentication, workspace, scheduling, scalability, health check, monitoring. We use key clock for identity management, post-grad database for persistent data. But chair server is actually the control part that creates workspaces. And workspaces is basically, as I said, a port which consists of containers for IDE, for runtimes, for development, for tools. In chair server, we define in a new kind of workspace. So, we contain a rise in the IDE with zero install and automated configuration. So, that onboarding could happen just with one click. And you might recognize similar UX to the VS code. One thing is that Eclipse chair uses, by default, TID. And TID is basically promoted as a VS code in browser. It uses the very same editor which use VS code. It's called Monaco editor. That's why look and feel is very similar to VS code. We have support of language server protocols and debug adapter protocols. So, I showed it in the demo. And one of the most important things here that Eclipse chair is compatible with VS code extensions. How we achieve the replication of the environment, the brand you think is also def file. If you are interested in def file, I encourage you to visit tomorrow a session dedicated to def file. It's called development environment as code. I will only touch the basis on that. So, basically, it's a YAML definition of your development environment. So, for my application, it was something like that. So, I can show you the raw version of it. So, in this YAML file, you explicitly specify everything you need for your project. So, starting from the containers, going to the tools, build commands, databases, et cetera. So, here, in the declarative way, you define project, IDE, built environment, runtime environment, test environment commands. It's the idea is similar to what, for example, build tools like Jenkins promote that they have their file and Jenkins understand it. So, here, we have def file that Eclipse chair understand and creates the environment for you with all you need for development. So, again, encourage you to visit the session. Folks will tell a lot more about that. Quickly, talk about the roadmap. Our roadmap for the next six, 12 months is split into four major sections. You can find it on the Eclipse GitHub in the Viki page, but basically it's just the following. Easy to use. We want to make it easy to use. We want to improve developer experience, improve performance, and the last button of this part is hybrid clouds. We want to allow not only running the containers, but also building the containers. And there are already proof of concept with Podman for that. And if you want to try it, you should go to eclipseorg.deshchair website. Here you can find all the getting started guides, downloads, documentation, reference to our Matimos channel. So, feel free to join. And the last but not least is that we also have hosted version of Eclipse chair. It's called chair.openshift.io or eclipse chair hosted by Red Hat. And the easiest way to try it is basically you go to eclipseorg.chair. Then you have this SAS Workspace templates. And here we have a set of dev files ready to go to start, you know, quoting instantly on hosted version of chair. So here we have Spring Vertex Go, Java Gradle, Java Maver, Node, et cetera. So you just go there. You click a button, for example, Go, Launch Workspace. And you'll be redirected to the Red Hat login page. If you have an account that's fine, just log in. You will be provisioned with a new user. If not, create an account and you will get access to hosted version of chair. That's about it. I think I'm on time and we have four minutes for questions. The question was what languages are supported? So the thing is that we support multiple languages. We have the language server protocol. And you can find all the languages that are supported at the Eclipse plugin registry. So there is a repository that is called Eclipse plugin registry. But literally it's Go, Node.js, Java, Python, PHP. There is a contribution for Kabul, I think. There is unfortunately no proper document that shows it. But if you go to plugin registry, you could find all the things that we currently support. Because it keeps growing every day. Currently I think there are around 60 language services. Not all of them are contributed to chair. But it's every day it's enhancing. So the basic one is supported. Next question. So the question is what amount of work is required to support a brand new language when there is already a language server? I think it should be relatively easy. So if it is supported inside the VS code, it should be quite easy to backport it to Eclipse chair. It should be actually just a matter of embedding the VS code extension that provides a support. For example, we got a support for Quarkus. And it was just a contribution of the embedding of the VS code extension. So there might be some API incompatibilities between VS code and TIA. But in general, it shouldn't be very difficult. As soon as there is a VS code extension, the porting new language to chair shouldn't be a difficult task. Next question. So looks like no questions. We're just on time. Thank you very much for coming.