 Hi, welcome everyone. Good morning. So my name is Alison Yuan and I'm one of the hosts and this is John Paul here. Yeah, so we work on Eclipse CodeWinds and we're here to talk about how it integrates with Eclipse Che, which there's already been a couple talks on. Yeah, so I quick introduction to myself. I'm the development lead for the integrative development for Cobling. I'm also involved in a couple of open source projects as well. I'm the Eclipse WTP web tools platform, DMC, and also the hard-to-leaf for WTP server tools as well. And now I'm also a project lead for Eclipse tools for Cloud Foundry, so I've been in the open source project around for quite a bit as well. And today we're going to talk about specifically on this Cobling project, which is a brand new project we started on in February 2019, which is still a fairly young project. So John, would you like to introduce yourself? Yeah, so I'm John. I work with Alison. I focus primarily on Cobling's integration with Kubernetes and Eclipse Che. So it's nice that I kind of get to come here and talk about it. Okay, so let's get started. So this, you can follow us on Traders or anything like that. So this is our agenda today. So what we are going to talk about today is I just want to talk a little bit on the background on cloud native development to Cyworth. And then we'll go straight to talk about Eclipse Cobling and Che as well, and then why we are using Che in the sense that to work with Cobling. And then how do we actually plug into Cobling and talk about some of features and of course a session without demo will be a little bit boring. So of course we'll do some demos in there as well. So if you have any questions during the presentation, stop me and then feel free to ask questions along the line. Okay, so let's talk about background a little bit. So let's talk about cloud development first. So cloud deployment, typically if you're going through a cloud deployment, you will be going through a CDICD pipeline for which you will be checking your code into team repository. And then your code will get picked up and then the pipeline will go through all the necessary stuff to do the build test and go through a cycle and do the deployment. Now this process is from the deployment perspective is great. You've got a very stringent and every time you go through the process is good. But if you actually have to do that during the development, you're not going to check in every single line of pieces of code into your team repository when you're doing your testing on it. So you definitely need something before that, before you check into that, and then before you actually do the deployment. So what's cloud native development? So if you think about cloud native development, we're talking about the applications that are running within the containers today that you are intended to deploy to a cloud. So dealing with applications that's running inside a container, when you're doing development, there are certain things that will kind of block you from that. But then the main reason that you want to do that in a cloud kind of applications is because it's basically you're running through your development. You're actually running in a container which contains your stack of run times and then your libraries and any fixed pack or anything, any software that's needed. So basically it's the same type of environment that you have on your production. So if you are running a development in there, then once you do the development by the time you complete, you almost can be sure that you're actually running in the same, it will be working in your production environment as well. So that's why there's some benefit on doing cloud native development. And then you can actually test directly the output of the build. So because that's what you're actually running as production. You can also do service injections as well because it depends on how and where you're actually running your development on. So in some cases, you're actually testing directly on the cloud for which this is the focus of what we are going to talk about in the shape scenarios. In some cases, you may be just running on your local system or maybe running Docker containers directly on your local system that can work to and go in actually supported to. And then Joe will be able to debug on that. Given that the application is actually running within a container, there's a little bit of indirection. It's not the actual server that's running on your local system. It's running in your container. You need to expose the port and stuff like that before you can actually do a debug on that. So there's some indirection on that. So cloud native development, so history. In so far, many people are actually doing local type of development in place. You've got your local IDE. You've got your local runtime running through that and then trying to check into GitHub and then pick up by CI CD pipeline. Now the history of that, like people are assigned to moving more and more into cloud development. In a sense, there's a slight delay on what we are actually doing deployment. People have much more cloud deployment these days, but doing direct development on cloud is slightly different because there's some penalty associated with that. Now, if you are running containers, you need to solve the containers. You need to build the containers. That takes time. And then iterative development, which is the other thing. If your application is running within a container, let's say if you recycle a container, the server gets resided. The container gets resided. You lose some of the state in there. There's some setup that you can actually do to prevent that. But then accessing logs, even as simple as accessing log files, right? Because you will have ECSS. If you're running on a cube system, you can actually get the logs from your container output. But sometimes your server has more than just the container output. You've got other server logs. You've got some of the error logs that is actually producing specific to that particular server that sometimes you find yourself have to shell into it and basically execute into the container in order to find out those logs and stuff like that. So even as simple as log itself, if you're doing a container type of an environment, it's a little bit more difficult. So choosing code win is just to help you out to reduce those tags when you're doing application development on a container. So we can talk about that, how we actually do that. So code win. Code win itself is an open source project in Eclipse starting on February 2019. There's actually a little bit of history on that. There's a project called micro profile, which is an IBM internal... Micro climate. Micro climate, which is an IBM internal software on that. It's not an open source. So we later find that when we look across the board, there are many companies doing different things on how you're actually doing native development on that. There's not standardized ways to do it. That's why we start up this Eclipse code win project to do that. So basically it's a cognitive development environment for Kubernetes. In a sense, code win vision is actually slightly more than Kubernetes. We also support local type of seniors. So kind of breaching you, allowing you to basically run and test on your local system still in a containerized environment. But then you can actually move to Kubernetes as well, and that you're doing testings. It provides ways for you to rapidly create and develop your application, doing debug on it. Anything that you would expect on a typical development environment. So before I move further, any questions so far? Okay. Actually, people at the back, are you hearing me okay? Okay. All right. So there's many styles for building applications. So I just list a couple of them. You can do a custom Docker build on that. You've got Sodeo, which is an OpenShift CLI on that. And then Scaffold is another one. Code win currently just to showcase, we are actually kind of build structure independent. We actually support three different types of build systems today. So code win, what we call the code style. The first style is basically you've got Docker containers. You can actually, for this one, you've got complete flexibility on your applications. You include your Docker container information. So your Docker files is actually part of your project. So you have full control on the environment that you have. You can actually, like those containers building, it's actually part of your application. So the entire stack is actually within that. Then we've got the absody. Absody is another open source project that's going on. That is a kind of end to end scenario for, it's a self, it's a CLI, but it has also defined stacks like application creation. It's got templates associated with that. It also has got some of the architectural roles in there. So you will expect enterprise architect to be defining how you build and how you actually run your applications. Then the developers will be just using that type of environments and then just focus on doing your application development from there. You can also adjust a little bit from there as well. And then OpenShift, this is a S2I based model. It's running on OpenShift only today. There's actually a job effort with our team, with the Red OpenShift team, just to make Odo itself to be more kid generic so that we can actually run across on that, on top of not only OpenShift, but any Kubernetes environments as well. So why Eclipse? So we open source it simply because we want it to become a platform. As I showed earlier, you can have different build systems. So no matter what build systems you have, you can actually build some extensions in it and then you can actually run as part of the cooling framework. And then Eclipse itself is actually the Eclipse Foundation. I've got a long history to start with. And then many of the development tools is actually part of the Eclipse Foundation as well. If you take a look across the board, Eclipse IDE most obviously is one of them. And then there is that shade. There is the editors. And then shade itself is where we are doing integration with. All of them are actually under the foundation. That's why we decided to go with the Eclipse Foundation on our open source project. So let's move on to Eclipse shade before later John will talk about a little bit more on the features on what we provide for COVID. So Eclipse shade itself is fully hosted. It's a Kubernetes IDE, native IDE for it. So it allows you to develop your application. Basically, shade itself has got a third editor by default that you can actually just run from your browser. You can actually access the system from COVID and you can actually do development in there. It's a fully hosted environment in there. So you can actually do end-to-end development in there as well. So it's got ISP that you can actually... There's a language server protocol as well. So there's many things that you can actually plug into as part of the Eclipse shade platform. So the way that they're doing is... They've got different depth files basically defining how the workspace looks like. So the workspace, consider that as a complete end-to-end things that you can actually define what your editor is, what are the plug-ins that you have as well, and then what are the sample applications that you can provide as part of the shade. So when you're loading up a workspace across multiple developers on the team, you can just load up the same workspace and you get the same development environment to start with. If I'll add, there was actually a great talk yesterday about the shade developers on what depth files are and what they're really capable of. And I don't know who here might have attended it, but I really do recommend checking out their slides online after because it gives a great insight into exactly what depth files are. Okay. So why do we choose Eclipse J? So just to take a step back on that, Co-Win itself can actually run... Itself has got an Eclipse plug-in in there. So if you go to Eclipse Marketplace, you can just download it. That one version is fully local type of environment. You can actually run Docker containers on it. You can still do containerize environment application development on that. We also support VS Code. VS Code is the NARA editors that we provide as well. So those two are all local scenarios. We're actually working on IntelliJ as well. So we can actually plug into many different environments. So those two particular scenarios are more for your local environment. We also are working on a hybrid kind of cases. But then Eclipse J is where we see ourselves when you're writing fully hosted. So if you don't want to set up anything on your local system, you want to write everything from Kube, and you still want to do containerized development, that's where Co-Win plug-in to Shade on that. So one of the reasons... Shade itself is good because it's multi-cloud workspaces. So you can actually set up multiple workspaces. You can have different users setting up the workspaces. You can just do install ones on there. And then the other thing that I really like about Eclipse Shade for the integration is that you can actually run VS Code extensions in there. So if you recall, I mentioned we've got a VS Code extension that's running on local. We can actually reuse the same VS Code extensions when running on Shade as well. So yep. Do you want to plug in for VS Code? No? Sorry? We've got an extension for VS Code. We've got a VS Code extension. We've got Eclipse talking as well. Eclipse, of course. But then we're working on the entire version. No subline. Not yet. So we're looking at other things, but yeah. So subline in those cases, originally the way that we are planning is we may be doing more like a command. We'll do that in this type of integration because there's too many editors out there. We have to pick and choose at some point. So yeah. So subline is a good one. But yeah. Currently it's not. Okay. So there are a couple of benefits of Shade itself. It's a security constraint and development. You can actually go as good security model and then you need to log in into your Qt system and you actually got some good security modelings there. You can also testing and debugging directly from the Qt as well. So just for your background, just to talk a little bit more on how we actually plug into Shade. So yeah. As I mentioned, we've got the base code extensions in place. But then when we are working on that, we don't actually have to do a lot of work. We end up sharing around maybe 95% of the code basis between a local environment versus when we are running on Shade. There's only some very small differences between the two. So if you are running using our local system and then now you're moving to a hosted Shade environment, you actually get pretty much the same type of usage behavior that you're seeing from local. So if you want to run your local and then you want to later move to Qt for doing your development, it's an easy transition for you. And then when deploying, the way that we do is we also meet use of a DevFile that I mentioned before. So basically we've got a DevFile that you can actually install code wing on top of that. Then you can actually run a start-up workspace with code wing installed in there. Then you can just run from there. So this is a little bit of BC diagram. I don't expect you, I'm not going to go through too much on that. So just to give you some ideas on different pieces that we are actually plugging into the Shade, the fare editors itself, we actually got some extensions put into there. That's where our ESCO extension is. It's providing the views and all the user questions that we have on the editor itself. And then we've got a sidecar, which is like a communication channel between the two. And then we've got the code wing engine. So the code wing services, what we call a PFE, which is the build engine. This is the same build engine that we are reusing on your local system. If you're running your system, if you're running directly from Eclipse or directly from ESCO, it's actually using the same engine for doing the building. So that's why we kind of put that concept and take it around. So that both your local and your cube cases, when you're doing the build, they are actually behaving fairly identical in terms of it. I guess the only difference is instead of we're using upper portions of it, then we are actually using code deploys for doing the application. So those are the main differences between the two. So just to give you a feel on how easy for you to plug in or create a data file on Shade, not too much of that going on in there, you really have to, this is the entire plug-in that we have on Shade, like the data file that we have on Shade. Basically defining the ID itself and then you can define what the site card, which is the containers for running our communication layer on that. And then we've got the Shade plug-in in there as well. So that's pretty much it. So you can see how easy it is for us to actually just plug it into the Shade system. So let me pass on to John to talk about the features a little bit more. Before we do that, any questions in general? Okay. All right. Cool. All right, so yeah. So this is kind of, so I'm going to talk about some of the codewind's features before I kind of dive into the demo. So it's kind of kind of the codewind overview page in the code's chain. So it gives you an idea of your project, its status, how it's exposed, a URL where you can access it, last time it was built, and in addition to that, you're able to shell into running containers. We support multiple types of projects, as Alson mentioned. We are polyglots, so you're not constrained to any one language. You can build Go, you can build JavaScript, you can build Java, you could build Scala, whatever you want you can build if you've got Dockerfile or S2I-based Image Dream, whatever. So yeah, like we mentioned, we support OpenShift Do or Odo. We provide a CLI for OpenShift. So we provide a wrapper for it and that wrapper allows you to take your S2I-based project and deploy it onto Kubernetes and wrap the iterate against it for changes. So this is kind of an idea of what Odo does and then we kind of wrap that all up for the user. You don't need to actually learn any of those commands. We do it for you. Again, as Alson mentioned, we also support App City. Again, it's a CLI to enable you to easily create, build, test and deploy your application from easily from a set of runtime stacks. With Kodman and Shea, again, we provide support for the CLI, allowing you to easily deploy App City applications onto Kubernetes and this is kind of an idea of some of the applications that we support. And yeah, similarly, we have built-in performance monitoring. So it's a lightweight live performance monitoring for key metrics, including HTTP response, throughput memory and CPU use, available metrics based on language. So Alson, currently JavaScript and Java, I believe. Yes, both Java, SerpentScript and Java. So one of the main things why we actually introduce performance monitoring in place is because if you think about on a typical cases of development, typically you'll be going, like you don't do performance monitoring right at the beginning or during your day-to-day development cycle. You'll be more like checking into Git and then going through the CI CD pipeline and doing performance testing as part of that. That's a little bit late in the cycle. That's why we introduce performance monitoring for which it allows you to basically monitor as you are typing. I'm modifying this line of how does it actually affect my application. So you can actually do that right at the beginning of your early in your development cycle. That's why we inject it in there. Yeah. We've got a load testing dashboard. So again, integrated form-session dashboard. You can easily run repeatable load tests against your application endpoints. Easily configurable, including payloads. And you can compare results against historical performance to spot regressions. Yeah. Similarly, we have an integration point with Tekton. So if you have the Tekton dashboard installed on your cluster, we can detect that and you can easily open it up from CodeWinNunche to deploy your applications through Tekton once you're finished iterating. We do have a feature work plan to integrate the developer's view of the pipeline directly into the IDE, but that's not in place right now. Similarly, we do have OpenAPI tools. So it usually generates client or server-side stubs for rest interfaces from OpenAPI definitions. Currently, it's only for Eclipse IDE and VS Code. We do however have plans to add support as a standalone Eclipse-shaped plugin that you can install alongside plugins or independently on your own. Alright. And then as a Tek Preview, we also support like Alston mentioned, a kind of hybrid scenario. So using a local IDE, you can deploy into a remote Kubernetes cluster. And potentially the same cluster using what you're developing with CodeWinNunche. Right now, it's in Tek Preview and it's supported on the VS Code and Eclipse IDE extensions. And yeah. Quick, I guess, call out some of the open-source projects we're working on and that CodeWinNunche has integration points with. They're all part of the Cabinero open-source project, which all of these belong to. I'll actually show, yeah. Currently, it's the last one we've developed and we used a mini-cube on the on-shoot. So can we configure it with a mini-cube but then jump and do the jump first in another environment? Yeah. So... Oh, yeah. So he was asking if CodeWinNunche supports mini-cube and yep, we do. I was actually going to do the demo today on mini-cube but the internet here was a little too slow to set it up. So I fell back on one of my pre-setup clusters on OpenShift. So the main idea is that we've got the local type of environment that you can actually run in local because that is actually faster in the sense that you can do development on Docker directly. Just all still containerized space. And then after you are happy with that you... That's why we've got the hyper-supporting place that you can actually, without leaving your ID, just publishing that and then trying to do development directly do development on the on-cube system as well. So that's why we've got all these stuff in place and then after you are happy with that then you maybe do... Or if you want to do a combination of that you can do a fully hosted environment on the shade scenarios as well. So we tried to cover as much of a scenario as possible but typically as a developer myself I typically like everything running on my desktop machine whenever it's possible but simply because it's quicker I don't have to always have internet access and stuff like that. And yeah, and one of the reasons we liked or why we initially started looking at Che was it was kube generic. You could run it on any cloud and similarly Codemon itself is kube generic you can run it on any kube. So they kind of work nicely together so it doesn't matter if it's mini-cube OpenShift or your... CRC? Yep. Do you test it with CRC? Yep. So any kind of local kubernetes offering we've also tested desktop kubernetes as another one. All works fine. The only really requirements we have and that's similar for Che is that you have Ingress installed and set up otherwise it's... you can pretty much run it anywhere. Alright, demo. Any other questions before I get into the demo? Alright. So I'm just going to show you how you actually can set up a codewind on Che Workspace and what it can actually do because you guys don't want to see just a bunch of slides. Alright. So, let me pull up a browser. Alright. So, first things first. So we mentioned the codewind dev file we have, you know, it's developer workspaces as code. So, realizing now I didn't open a tab for this before so I'm just going to google the codewind che plugin and we're just going to grab that so I'm just going to grab it and this is our latest release so I'm just going to go this and I'm going to log in to my Che cluster. There we go. Alright. So the only really requirement we have before you can go and create a codewind on Che Workspace is you have to apply Kubernetes role and role binding to Che itself before we can get deployed and that's because codewind itself requires additional roles and Che Workspace gives you. So to do that Oh. Yep. So it's pretty straight forward. I'm just going to go save here. So our docs highlight this too so you just go to your terminal and clear and you just run that command and that will create the role and role binding on the cluster. There we go. Network is still a little slow. Alright. So back to the browser. So we so we take that defile and we do go to import defile go to source copy and paste and you hit create and open and so this will run. I don't feel like this is going to take a couple minutes. I don't feel like showing this for the demo so I'm just I've got a Che install with this already set up. So I'm just going to log in. Oh. Let's see it. There we go. Alright. I'm just going to maximize this. Can you guys see this? Do you want me to maximize it all? A little bit? Okay. How's that? Alright. So got Che running. So that load. So it's bringing up Thea and then once that's done you'll have Che. Fingers crossed the internet cooperates today was not cooperating yesterday so I'm hoping this does not fail. Well this is loading. Do you have any questions? For the code one plugin as a whole? So yeah. So he was asking what's the memory of the code one plugin as a whole? So between code between the code one sidecar and the code one instance that the sidecar then deploys and manages it's about one gigabyte plus or minus a bit in terms of memory. But in order to run that then you also have to take into account of your application container as well because I'm running 10 of those applications together then you'll take up more memory but those are more for your application self. And again code one can deploy small microservices, large Puge applications we've had in the past a demoed a game called Rogue Cloud on it where you can kind of using code one you can kind of code your own AI and have it deployed live into the game which is kind of cool. Alright so this is code one. So this is a simple chae workspace. So this is kind of the code one view this is kind of what the code one VS code or extension manages. So from there you can see we've got two applications deployed Java micro profile one and a small node microservice. So from this view you can easily generate an application from one of our templates or you can do a get clone from Thea and pull in your own application. We don't have a whole lot of requirements on that whether it just be a simple docker file and helm chart or a simple S2I some base application. So for this I like go so I'm going to do a simple go microservice and give it a game do go project and it's going to run through. So code one will do the get clone and it will add the project so close this debug output and so yeah it's adding the output so it looks like the CSS is a little buggy right now that's alright. So this is kind of the code one project overview page from there you can see like we mentioned earlier the status of your application the last time it was built what type it is and what ports are exposed and what endpoint it's running at. So you can see there's an application endpoint an internal app port and if the project also exposes an external port it'll show that as well. So you can just click here oh did not mean to do that and yeah that's pretty much it so similarly you can easily get the logs for your application so this makes debugging a whole lot easier you don't need to go through like a kubectl or any other CLI to find the logs it's right there in front of you similarly pretty easy to get the application logs this doesn't give you a whole lot of meaning but it is straightforward to get both logs for your application yeah and so similarly you can easily manage the types of projects and templates your codewin pulls in so we've got codewin style projects which are dockerfile based and helmchart based so the only requirements there that you have a dockerfile and a helmchart in it then we have appsy style projects which then just pull in the appsy CLI which ones will be supported will be based on which stacks are available and that's what those templates pull in and then we have openshift templates which are based on the openshift docli and those will be based on the image streams available on your openshift cluster yeah so so openshift do I'll showcase another project dude what do you know so it'll go through, it'll create it this time it'll use the Odo CLI to deploy the project and then redeploy when changes are made any questions so far no so the current don't quote me on that but our current plan for that is like first quarter we're going to have some type of pet review going on at least that's what we're shooting for of course the pace can be moving but that's the timeline that we're looking for so again what we mentioned is we watch for changes so it's pretty straightforward to make a change with codewind save it and that change will then get picked up from our side we'll build the application and redeploy it and we'll take the small steps possible to reduce the amount of build time so for go we don't do a whole lot we cache the image build so we only build the steps that are needed and then in this case we do a helm update rather than a helm install so we only replace the parts of the application that needs to be so it's built through one thing I forgot to mention was when you're we also have an image registry manager so if your application needs to push to a docker registry you can enter in your credentials there and add it through so yeah if I open up this application now you can see it's been updated yep yeah so that was codewind yeah yeah so it gets built inside codewind so he was asking where does the docker image for the application to get built by codewind using the build CLI and so we build it inside codewind and then it will get pushed up to the registry specified in the image registry manager I just showed yep yep yep yep yep yep yep so yeah docker build itself is very cache so we are actually reusing the same container for doing the build so we're not spawning off a new container yeah we've got a build container it actually depends on the coding style that you have like we're talking about the codewind style which is our docker build style it's actually staying up there with the build container is actually always staying up and we are reusing it so docker cache is actually preserved in that case same for maven cache and stuff like that if you're running maven builds and stuff like that whenever you are spawning off a new build we are not recycling the container we are reusing the same container now the only exception so the running environment it actually depends on the application type that you are dealing with for example we've got a micro profile type of applications for which it's actually run time and build as a single container the server will get recycled but the container doesn't actually get goes down now the only case that you're really bringing down the container you may lose the cache is when you're actually modifying the build container talk about then your container needs to be recycled and you will lose some of the cache but even that's the case for example things like maven and spring in those cases we are actually kind of caching some of the preliminary cache in place and we are actually minimizing the time for you to rebuild those cases the other thing I would add too it's entirely up to you you can totally format if you want your Dockerfile to have multi-stage builds multi-layered builds and kind of follow the Dockerfile best practices you certainly can we support it nothing will prevent that as well the microservices we're demoing here at least are a little simple they don't necessarily require it we've got more complicated project types more complicated templates they do have that exactly so yeah that was the demo any other questions before I move on a little bit about of the code green view I just wanted to sorry I'm would you be a little bit more on the right it's like a cube oh sorry sorry no worries and if you open code green's chest side yep so I'm wondering so could you open the terminal and basically you actually embed all the tools like although although and stuff like that all are available in this not this terminal but we should repeat the question and embed all the tools in that kind of plugins container not in this container but something that would be worth considering at least so if you recall the diagram like the architecture diagram that I showed earlier the sidecar is more like a communication between the and also our build engine for which our build engines we use on the same like it's actually a different container we actually use on the local cases so the most of the build logic is actually within that extra containers it's not directly on the sidecar from our perspective it's more for doing file watching mechanisms and also doing the communication transfer through the actual build system itself it's actually running on a different container yeah I'm just what I'm not entirely clear is where the builder is running where the author is running so how you do from the ID from which container so it's the it's the PSE container that build engine the green part of that that's where all the things is running if you take a look at the yellow thing that is the yellow part of it is everything is actually within the the chaid part but then the container itself is actually running outside of the chaid part but within the same namespace yeah any other questions alright let me continue on from okay so so our website is codewin.dev or eclipse.org same site visit us you can follow our documentation and see how you can actually get codewin installed on eclipse chaid or some other platform use our website use our github link so our eclipse slash codewin is eclipse slash codewin chaid plugin we're on matter most with eclipse slash dash codewin and eclipse dash codewin dev we're on twitter and our eclipse.org mailing list now one thing that I want to mention we are open source project so not only we welcome users we also welcome developers as well so if you find bugs or stuff like that open an issue on us even some people request on us we're looking for developers on the project itself so we're not only we're looking for users developers are always welcome for us so it's a bit of he was asking what languages codewin is written in so it's a mix of languages right now so the build engine is written in typescript as well as codewin and thea extension that we're running also typescript typescript is the majority some commands are written in go and a small bit of a legacy portion is written in java in terms of the build engine but of course the eclipse plugin itself is entirely in java so it does have a range of languages that we are actually involving it's probably too much in a sense eclipse id plugin is not the legacy part that I was calling here we are that's good that's it any questions comments the last question is I suspect that there was a VS Code extension and then you embedded in chat so what was your experience for 14 VS Code extension to eclipse chat was it smooth or you had some key cups so let me repeat the question first so the question is we are actually adopting our VS Code extensions in chat during that experience is how do we find the actual adoptions is and how easy it is to do that overall it was pretty easy now the lead thea extension developer for codewin isn't here but we worked closely with them and overall again probably 95% of the code is identical a small portion of it had to be changed between differences between the thea and VS Code APIs and then the rest of the difference is to accommodate scenarios that only exist on chat and not say VS Code at the beginning of the adoption we do find a couple of there related especially some of the stuff on VS Code not quite working as is on the there in there so there are a couple of things that we actually were doing to fix on that but after that is fairly smooth sharing I would say thank you and I guess another thing to add on to that are the code base is so almost identical and close together that it's the same repository, same building scripts the only difference is our CI scripts spit out two extensions which one you install we basically do a codewin.v6 and despite the name it's not a thea extension it's a VS Code extension any other questions okay that's it, thank you