So I first learned about environmental justice in 1994, second year graduate student, when quite a bit of media attention was focused on a report that was published that described how non-whites were three times as likely to live in a zip code with a landfill than without a landfill. And as a graduate student studying public policy and the environmental policy in particular, this was, you know, groundbreaking news, big news. It obviously came up in our classes and we started a conversation around it with professors and my peers, other PhD students, and eventually a group of us led by some of our professors decided to write a proposal to try to get money to support research to help us better understand the problem of environmental justice. And so we started working on a proposal probably, and we went through several iterations and five years later we finally got a grant to study social vulnerability and toxic hazards. You know, there were several important questions that kind of framed that grant about the scale of toxic exposures but also not all pollution is created equally. So another part of our question was to look at the riskier kinds of chemicals and riskier emissions that were being released into the environment. And then finally creating an index of risks that those kind of three issues and three questions have really driven a research program and my teaching and the collaborations with students ever since. That span of time as a graduate student it was, and in focusing on the environment, it was the biggest controversy, biggest story, biggest challenge that many environmental professionals were grappling with at the time. And so it was in a formative moment for me as a doctoral student but then it helped me remember a moment college as an undergraduate that I'd written about for a class. I was an undergraduate working on my bachelor of science in public health and my concentration was environmental health. But we had to do a practicum and that practicum is like an internship where you had to do environmental health related work. So I actually got a job working for a safety engineer at Stuart Warner Southwind Manufacturing. Pretty large facility in southern Indianapolis and it was being shuttered to be replaced by a newer plant in the southern part of the state. And so there were lots of parts of this big facility that were basically abandoned. And my job was to go around and find unlabeled 55 gallon drums. It was kind of a well-lit industrial shop of horrors. Unlabeled chemical powders, drums of hazardous waste that I had to sample and send off to be tested and identified. But there was one part of the plant that was still running. But one day when I parted the kind of industrial sized refrigeration curtains, my upper respiratory system went into full alert.  And there was clearly something going wrong in the operation. I yelled above the industrial noise that they needed to get out or something wrong, evacuate the line.  But as they kind of walked by me single file through that opening and those those kind of floor-to-ceiling curtains it I noticed they were all African-American. And as one of them walked past me he really looked me in the eye and I can remember that you know like it was yesterday because he asked me where were you 20 years ago. And as I kind of remembered that moment in the 90s and as I started thinking about this challenge of environmental justice it I began to realize that I saw environmental justice that day in Indiana but I didn't even know it. My training didn't prepare me to recognize it. It's definitely still happening today and I can see it and that the students I work with can still see it so it's it's still here still a problem we're still fighting for environmental justice.


So, today the topic which myself and my colleague, Dinkar, we are going to do is about zero-to-hero in Kubernetes native Java, changing, you know, landscape of computer or in the software industry. The synergy between Java and Kubernetes has led to the development of this term, which you hear Kubernetes native Java. How many of you knew about this one? The Java flavored, which is, okay, very good, just one. So, when I talk about zero-to-hero, the thing is that by the time you walk out of this session, you will have a fair understanding of what or how Java has evolved, and my next few slides are going to talk about evolved to meet the current landscape, and we also have a demo around it, okay? So, let's go ahead and talk about this. All of you know that Java came up in early 90s, right? And Java was brought out to meet a certain kind of requirement, right? In that world, there were no containers, no Kubernetes, nothing. It was just plain, you know, free tier or end tier architecture wherein we wanted to have applications which will, or enterprises wanted to run their mission critical applications, and then Java was a language which was evolved. It is something very similar, and over the years what we see is something very similar to the Cambrian explosion of biological diversity, wherein we saw new life coming in similarly in the landscape of computer development. We see that there has been a population of languages, frameworks, you know, different kind of things came up, right? And you can call it anything. You can call it the architecture patterns. You can call it, you know, the evolution of microservices from a monolith to microservices. End number of things came up, right? And finally, today we stand in a day wherein containers, Kubernetes, is the talk or the buzzword around, digital transformation is the buzzword around, and all of us are talking about it. Now, I want to talk, while I move to, before I move to the next slide, I want to tell you that when we talk about Java, or a setup for a Java, it included a very expensive hardware, very expensive software, and also the maintenance, the annual maintenance of that software was also very critical. So end to end, the total, the cost of infrastructure was too high, and to support that we built complex applications like web, like web server, application servers to run them, to use this complex architecture, right? So, but with changing times and with arrival of cloud providers, what we saw, that this cost of entry of this, you know, small or medium businesses from a very high, which was earlier in the times of Java to the tune of half a million, came down to close to zero. Now, you are able to understand how things are changing, right? This is close to zero. Now, Java's relevance is under question that why should we spend so much on a language, or you know, procuring or running an application, which is so expensive, wherein, you know, the cloud providers are showing us a way, wherein it is close to zero. Now, to prove my point, I have this slide, wherein it is a study done on the developers, the serverless developers, okay? But what they are doing is, what you see are the languages they are choosing to develop. And when I'm talking about serverless, I'm talking about, you know, low latency, I'm talking about highly responsive application, I am talking about, you know, faster time to market, you know, so that whenever the need comes up, I am going to have that code block, code, the block of code execute. And therein, you see that six percent, Java surely is not, you know, at the top of these, you know, high performing developers or, you know, which are tuned to the market, right? So given this, Java, we have to understand was designed to make the most or take the maximum of the network throughput, right? It was not designed to think of any other things as to what resource it is going to consume, how much CPU it is, how much disk it is going, that was not the thought process. The thought process was that it is designed for maximum throughput, right? And the one thing it is, that it was designed to be long running. If you have been around when Java was there, people were thinking about the critical applications would run for months together, or for years together without it. And restarting application was total no, no, nobody looked through it. If you are doing a rebuilding or changing something into the application, it was perfectly fine to wait for ten minutes, you know, operation team was fine with it if they had to wait for ten minutes to, you know, restart the application. And developers team was also okay. But in current timing, this is not something which we are willing to do, right? At the expense of the startup time, we are not okay with that. Just another thing, another proof point in my talk is that this thing what you see on your slide about the latest languages, okay, and the kind of, you know, performance, these languages, the pre-compiled language like Golang or Node.js, you are seeing very clearly that Java is, you know, consuming a lot of resources, right? Especially on a Contella platform. And as you move from left to right, you are seeing the resource utilization is much less, right?   If it really was, you wouldn't be sitting here. There has been a reinventing of Java, right?  But then, so many people have gone ahead and said Java is done. You cannot have Java into your enterprises anymore. But it is not really dead. And in that journey, Red Hat has played a very big role. So Red Hat leads the new age Java with open shares. And they have contributed, we have contributed from Red Hat into multiple open source projects, right? Temurim is like where we built all the JDKs which, you know, give a good build of JDKs to be used in enterprises. We have contributed to Crestat, we have Grail VM. So this contribution from Red Hat has ensured. It is in the garbage collectors with very low pause time so that it can run concurrently with the applications. So here in Java, in the runtime space, Red Hat has contributed a lot into all these projects, ensuring that the consumers or the users of Java continue to get the best of the breed or the best technologies which can be built around Java technology. When I look into specifications, Jagatay, Microfile and Hibernate, even here, Red Hat teams or Red Hat engineers have contributed in a big way, ensuring that Java finds its place into the modern world of containers and Kubernetes and microservices. Similarly, in the cloud native framework when we talk about and the topic of our discussion today, Corkus, Red Hat continues to be a major contributor. And just to add to this, we have a line of product in our product portfolio called Red Hat Build of Corkus. So wherein we support the Build of Corkus which we have built to our consumer and we give it to our customers. Now, just to categorize it correctly, I have put them into the support what Red Hat gives to Java Rantime, the multi-platform support. Red Hat contributes a big way into the ARM technology. 64-bit ARM technology we have ensured or we have contributed in a big way so that Java is acceptable or used across different kind of implementation on mobile, on IoT, on edge devices. Everywhere Java finds its place. Regarding securities, again, a big thing. FIPS, right? FIPS, right? It's a big thing in government or in banking and all our components like the Red Hat Build of JDK or the REL, UBI, they are all compliant. Most of our products are compliant on FIPS so that it can find its place into highly compliant or focus industries like banking, into government sector or defense, right? Similarly, performance. When we talk about performance, we have contributed into projects which are giving that kind of edge like the garbage collection, low-pause, very minimal pause, you know, we have into the garbage collection cycle so that it can run concurrently with the application processes. Similarly, the AQ assurance, right? So we are part of the community which adopteum quality assurance community which will build technology so which will ensure that all the features which are required for Java to be adopted into a microservices or cloud native world is made possible. So these are the capabilities in which Red Hat is contributing towards adoption of Java into the newer world on the world which is looking towards, you know, microservices, digital transformation which is talking about containers which is talking about low latency, talking about highly agile environment, okay? Now, this brings me to the caucus wherein we are talking about a highly cloud native or Kubernetes native Java, right? Which is largely written. It is cloud native as you can see. It is highly optimized to be used, very low footprint. Actually, we are going to show you a demo wherein we are going to show you the basic, the key features which caucus brings into it, right? And why it is widely adopted into the serverless architecture. What makes it the default choice for using in serverless, right? And in building of caucus, everybody has contributed. Even all these projects what you see, vertex, hibernate, rest easy, wild fly, they have all contributed in making or optimizing their specifications so that caucus is able to meet the requirement which the current requirement of a Java reinvent, right? Where Java can fit in into the newer setup, right? Now, if I talk about from a developer perspective, first thing what you need to understand is that the caucus has been built from day one in the understanding that it will be a language or language for the cloud, okay? For the cloud computing. It is from the very start, it was that it is a cloud native Java, right? And to add to that, it ranks into, you know, most of the top three programming languages, okay? Continued. And as you know, Java has got close to 10 million people. So for Java developer base, the learning curve is very less. The optimizations what you see, the different frameworks which are developed, the new things which have come up in caucus ensures that caucus continues to give rock solid performance, okay? And the tool chains which we have, the ID, the dev spaces, whatever we're talking are built in to be able to utilize caucus features to the best maximum so that the developers have the best use case, right? Whether it is CI, CD or the, when you have heard about in the morning session, you would have heard about the inner loop, right? Inner loop meaning how the developer is able to utilize the various components which are available for making a very, or developing into a very agile and a very fast, intuitive way of development, right? And there is a huge community which is available for caucus to help the developers with code blocks, with maybe blocks, with different other things, you know, code snippets, everything is available. So for the development, right? Development with caucus, these are the features which are available upfront to everybody to be able to get started with caucus and adopt caucus for a cloud native environment. And before I moved to the actual demo, I wanted also to talk about the business value, right? Divis in 2020, this is a forum which actually awarded caucus to be the top new language available, right? And why it got it? Because caucus showed few things. One, for the business, it is the cost saving, low memory, fast startup, cloud efficiency, very low learning curve because the 10 million Java developers which are available have very low learning curve for caucus, right? The cost saving is very high, right? And I showed you the density, you know, when we were doing that slide when I've been talking about the, you know, traditional Java application and the new age frameworks and the languages, you saw how the density is higher when we talk about caucus, right? The faster time to market, developer, productivity is too much. The ecosystem which I'm talking about, or I showed you in earlier slide, gives you very, and the low learning curve gives you very competitive, right? You will be able to develop or you know, the business will be able to meet the IT requirement very quickly, right? So whenever there is a change required, the learning curve is less, the tools are there and it will help you keep you in a very agile mode so that you are able to meet the business requirement at the shortest possible time, right? And the reliability, reliability again, is very important and Red Hat, and the next slide I'm going to talk about how Red Hat ensures that the companies which we are talking about and I already spoke about the UBI, right? The Red Hat Security FIPS components which we have built into our builds which ensure that the reliability factor is also very high when you use caucus into your environment. So from business perspective, the value caucus brings in is around low cost saving, around reliability, around faster time to market. Now, there are a few things from the developer perspective. It is a very cohesive platform based on standard but not limited to just to it. It is, you know, in the developer parlance, that either you can do reactive or imperative, but here in this, you can do both reactive and imperative all together into one application. You have lively reload, which is another thing which Java developers look forward to and apart from others, these few features make it very, very, you know, lucrative for a developer. The memory utilization, the performance, when you are talking about REST operations, you can see how low it is when we are talking about a GrailVM and caucus. The caucus GrailVM is as low as 0.14 seconds compared to 4.3 seconds when we talk about a traditional cloud native stack. REST plus curd operations, you see how less it is, it is 0.055 seconds. And we are going to demonstrate to you how the performance is into our demo as to how the startup time is improved by multi-folds when you are using caucus. So you will see the lively role, you will be able to see the higher performance, you will see the faster startup time. And also, the combination of imperative and reactive both together into one application. This is another feature which is very, very crucial, when we are talking about reactive, when we are talking about reactive messaging like Apache Kafka, MQTTT, AMQP, all these possibilities give a very big edge to our Java developer or a caucus developer. Again, caucus uses the best of the breed of frameworks on standards. You have all the list, all the seeds. There is a camel extension to caucus. There is MQTTP, as you already talked about, there is MongoDB support, then all these rest is Ehabinate, Microfile, all these support are available. Best of breed framework and standards are supported in caucus. Now, when and where are you going to use caucus? The first thing, when you are developing a net new applications or net new microservices like, any microservices based architecture, if you're developing, given the basic features of the new features of caucus, should be your choice. Serverless, okay, on-prem or on-cloud. You should look at adopting caucus, to avoid one vendor lock-in, or you know, don't look at caucus for a monolith to a microservices migration. Look at caucus for developing newer things, newer applications. And if you are developing IoT or on-the-age application, look for caucus in that, okay? So, these are the, what you see on your screen, other technical use cases where caucus can find its usage in a big way and can benefit the organization, as well as give the developer a lot of ease and joy in adopting caucus. Now, having said this, where do we see caucus? Many of you, at this point when I started, were not sure or not had heard about caucus. But caucus is adopted in a big way, in Lufthansa, okay? In their, you know, into their, you know, the repair center. Their application is running on caucus. Asia-Castaccio, this is a financial risk evaluator. They have actually removed all their, they have developed all their application, newer application, removed all their traditional languages and started using caucus. And so has Vodafone. Actually, Vodafone, Greece used to use Spring Boot. And now they use only caucus for all their newer developments. So, caucus is finding its way into bigger organizations like the ones which we have listed on there many, many more, which are actually using it, but we are not put it here because they are not a referenceable at this point. All right? So now I'll hand over to Dinkar to give you a demo. So, before I start the demo, how many of you folks here knew about caucus before you came here? What I have here is to see how we can get started with caucus.  You can actually download a caucus build. And so this is the CLI. And you can install that on your, I mean, just to get started and, you know, make things easier for yourself. Not only that, we also, if you just go here, you can start coding. If you click on that, you land up here, where we have something like a spring style configuration that you can choose for creating a new application. So let's say you wanna start with a new application. You can choose what kind of application do you want it to be, rest easy, reactive. I mean, this has actually, you know, thousands of configurations that are available. So you can choose these and it'll create a boilerplate application for you with all of these extensions pre-built. So let's, you know, just dive right into it. So what I have here, I hope everybody can see this. So I have caucus installed on my laptop and I'm going to create a new application. So the way you do it is just give this command, you know, caucus create app and then give it a name, you know, some name, whatever name you want. So you do this.  Okay, so just to put pressure on the demo guards a little bit more. So I have now here a directory called Quarkus demo, where if you just look at this, let me open VS code. So you can see that if you go into source, it has a few things here. So it already has created a Docker folder with a set of Docker files. It's got a Java source. It's just a hello world kind of a thing. It says rest easy reactive. And then there's a test associated with this as well. And there's a target. Now if you just look into the palm.xml, you can see that it has, okay, yeah, this is something that I forget usually. I am on the bleeding edge of Java, which is 21, but sometimes it doesn't work so well. So I'm gonna go back to 17. How many of you are using Java 21 here? Oh, one hand went up, nice. Okay, so anybody on Java seven? Okay, that's good. So yeah, so if you just look at palm.xml, it has downloaded a few of the, I mean, all the ones that we expect to be seen in a Kubernetes native application. So it has downloaded JUnit and a rest easy reactive application that I mentioned and things like that. So now let's just go ahead and so we have a mode in here which says, you know, quark, quark is dev. So what this does is that it creates that live loop, okay? So the local loop that we've been talking about since morning. So here you see that it was able to bring up the application, of course, I'm cheating a little bit because I've already installed the palm.xml, all the packages and stuff like that. But even then, even when I started with a fresh new thing, there are two things to note here. One is that the application came up in, so this is built plus, you know, the application got started in 1.6 seconds. Also, now that the application is running, so, you know, I just open up the port where it is running, it's local host 8080. So it shows that it is up and running. I go here, it shows you, you know, the rest easy reactive, hello from rest easy reactive, which is what we saw is here. So let's do some small thing. Okay, before that, how are we doing on time? So it took, you know, two and a half minutes. So now I'll just change this to, let's say, Dev Nation, okay? So hello from Dev Nation. So I just made the change and I'm going to go here and do a library load and it immediately comes up.  So it made the change, it saved it, and then it built the changes. I mean, it picked up the changes and rebuilt only those classes which required to be rebuilt and then it launched the application again all in 0.7 seconds and you were able to see this one. So this, only when I actually reloaded this, that triggered that reload and I mean, that triggered the actual build and then that's how we were able to see this. Okay, so now we are able to see this and it took about three minutes, right? So this is just a very simple, nothing fancy out here, but I mean, it gives you an idea of how quickly you can get started with an application and, you know, see it running. So the next thing is now we want to be able to, you know, obviously we've been talking about Kubernetes. So, you know, there's no fun if you just run it on your laptop, we want to be able to deploy it to Kubernetes. So what do we do to make that happen? So we need to add an extension. So you can say, Quarkus extension add and I'm going to say, open shift. So keep a look out on the target here, the target you see here and then let me add this. So when I added this, the live reload, actually, so that, you know, it is doing its work at the background that is going on out here. So, and you can see that it created a new Kubernetes directory and you see a few JSONs and YAMLs out here. So this one, what happened was that as soon as I added the extension Kubernetes or open shift to this project, it created the Kubernetes deployment YAML for me. So I don't need to worry about that. So as soon as I created the project, the Docker files were already there. So I don't need to worry about that. And now when I added the Kubernetes or open shift extension, it created the open shift YAML as well. So here, you know, there are, I mean, so the thing is that, you know, Kubernetes, there's lots of new things going on all the time and it's an entire world by itself. The question is, you know, do you need to know and be an expert in everything, right? I mean, do you need to be an expert in Docker, Kubernetes, Java and all the other frameworks and so on? Or do you just focus on your business logic and, you know, be worried about, you know, how do you do the best or, you know, fastest turnaround time in terms of time to market and things like that. So that's where this is really helpful. So, okay, so this just added this. So, you know, the open shift YAML. So now the question is, okay, how do we now deploy it and where do we deploy it to? So what I have here is, let me go back to this Firefox here. So I have a developer sandbox. Let's just get this here. So developer sandbox, I'm sure you've been hearing it since morning, it gives you your own open shift instance where you can try things out. Once you instantiate it, I think it's available for a month. I guess that's what Yashwant has been telling me here. So this is the sandbox that I have running. And, you know, don't worry about this one. There's some, you know, application that I had it running, but essentially it gives me a space where I can deploy my applications too. Now, what I'm going to do is to log in to this instance that I have from my laptop so that I can deploy the application that I just built onto this sandbox. So I'm going to go back here and let's do an OC login. So this is going to login into that particular open shift sandbox. So now I'm going to deploy this particular application so just to speed things up, I've got this command lines here, which I'm going to just add. So it's just doing a caucus build and saying, okay, deploy to open shift. So this is going to just, you know, do the same thing in terms of building and testing. And then it's going to now, oops, I forgot one thing which is that, you know, we made a change here to the code that said Dev Nation, but then I forgot to change the test, so the test failed. So this added a test as well. So, you know, obviously test-driven development, you need to start with the test first maybe, but then I'll make that change. So hopefully this time it should work. Okay, so while this is coming up, I think it's going to take some time for this thing to get pushed, okay? So this is, while this is going on, let's go back to the local instance. So if you go back to the local instance here and there's something called as a Dev UI. So this Dev UI is a sort of a portal for the developer to check out everything about the application that they're developing. So, you know, what are all the extensions does it have? So this is the configuration. So you want to make, I mean, Quarkus has literally thousands of configuration parameters. You can go in and edit any of those right from here. So it shows that, okay, these are the endpoints that is there. It even has a continuous testing. So for example, if I just do start out here, okay, this is still going on while that is going on. Okay, it shows that it's all done. Let's see how are we doing here. So, okay, the build is successful. So this means that the deployment has happened. Let's go back, check this one here. So you can see that Quarkus demo here. That's the one that we just created. Okay, one thing which I forgot to do was to do a O C expose and what did we call this, this is Quarkus demo. Okay, so this one is going to create a route for me. So basically, once you deploy the application to OpenShift, you need the way to access that application. So this is just a way to do that. So you can see that this open URL popped up out here when I did that. And essentially, yeah, there it says. So here we can see that it is running on the sandbox that I just created. If you go here, you have the welcome to Dev Nation, which is what we created. So how long did that take? Around 10 minutes. So from the time that we started fresh with a new project and all the way to pushing it to Kubernetes and having it running, it took just about 10 minutes. So now let's try to do something a little bit more complex with this application. I mean, obviously it's very simple. So probably the easiest thing would be to add a database and play around with that. So for me to be able to do that, the first thing is you need to add some Quarkus extensions. So to make it easy, there is a Quarkus extensions plugin or extension that's already available that helps you to pick the right extension for you. So here I want to pick Postgres. So I'm going to be picking the reactive Postgres SQL client because this is the default project that we created was a reactive one. And then we'll add the Panache reactive as well. So let's just add these two. So here it's updating the Palm.xml to say, you know, we are adding the two new, the extensions.  And while that is happening, I think you might have already also been talking about Podman. So what happened here is that you can see, I have Podman desktop running, and it says that it has downloaded a test containers and a Postgres SQL. So you can see that Postgres SQL is running 37 seconds. So what happened here was that when I added the Postgres extension, Quarkus detected that, you know, you don't have a Postgres SQL container running. And so it downloaded this, because I have this Podman desktop running, it was able to pull down the test container and a Postgres instance at the same time. And now I have a Postgres instance that I can play around with, you know, with just minimal effort. Okay, so now that that is in place, let's add a new class here. Let's call that person.java. Okay, so just to speed things up, I have the code out here. So this is, so this is actually a very simple, let me just talk about that. So here, I've just added an entity and the person class extends Panache entity, which helps you to provide most of the boilerplate code, like for example, the getters, setters, and also additional code like, you know, so we are going to use a list all. So that kind of boilerplate code is generated with the help of, you know, this Panache entity. So now I'm going to go to a greeting resource here and create a new endpoint. So add that here, a new path, let me just copy that here. So what I'm doing here is, I created a new path called, you know, slash hello slash people, where I'm returning a JSON type and this is actually returning the contents of what I have out here. So here in this particular Panache entity, I'm just trying to get the names and the Twitter IDs of the people that I'm adding and that is what is getting returned out here. So this is a person.listall. Okay, I think I'm missing something here. Just a second. Yeah, I need to choose this import. Oh, let me add the import here. That should help with that. Okay, so now that I have this, let's see if this is still running. Let me do Quarkus build again. So what I can do is now just test this application to see if I have everything in order.  So it is talking to the Postgreed database that we added, hold on, what is this? Yeah, I think I forgot to add one more. So because I'm returning a JSON object, let me add that extension. So I need to add another extension. That's the JSON-B, JSON-B reactive, this one. Okay, hopefully that should help. Let's go back here and do another Quarkus build. So hopefully this should bring up the application. I didn't need to do a build, but I've noticed that sometimes whenever I'm doing pom.xml updates, I might need to pull down the resources. So just to be on the safe side, I'm just trying to come on. Okay, so now that this is up, let's go back here. Okay, what's going on here? Okay, yep. So it's up, and now if I go back to the UI, and I go to hello, and then going to people. So I mean, obviously there's nothing to return, so it's not returning anything, but let's add something into the sources here. So let's add a new file called import.xql, and I'm going to go back to my editor. So I'm going to just add some contents into the DB here, which is getting inserted. So I'm just adding the name and the Twitter IDs. So now that this is done, I think I'm missing one more thing. So in the application properties, I need to mention that it needs to read from this. So let me just add that. I think this is what I had missed earlier. I had not created the route on OpenShift, so I can add that one and also make sure that the import.xql is right out here as well. So okay, so now that those things are set up, I can go back and do a Quarkus build again. I'm just doing that because I did a change in the configuration. Okay, so if I now open this again, or maybe I can just reload this. So it's able to pick up from the DB and show you the contents. So again, so just adding DB and populating it with some contents and just be able to get the quick feedback loop. So in just about 20 minutes, we are able to get here. So for you to be able to deploy this to OpenShift, it takes a little bit longer because obviously the configuration on, I mean, creating a database on OpenShift and being able to connect this instance with that one, it's a little bit more of a work. So I mean, because we have only about three minutes left, I have instance of this which is already running. So I'm gonna just show you the changes that I did rather than trying to show us something that's already running. So what are the changes needed for you to be able to run something like this? So if I go back to, okay, so this is another instance of the same application, but then with all of the proper configuration done to be able to run on OpenShift. So if you look at here, we have, so I've added a number of parameters here. So the percentage prod here says that, you know, this is only meant for, you know, the production, I mean, or the OpenShift instance and not locally. So I have a number of configuration parameters like, okay, what is the database kind? That is PostgreSQL. And then, you know, the URL from where I can access it, the user ID passwords. So those are obviously, you know, we don't want to hard code them. So they are passed in as secrets. And so you need to create a config map for you to be able to do that. And so I'm saying that use this particular PostgreSQL secret. And I mean, say that this is the secrets, config secret, Kubernetes config is enabled and that is where the secrets are stored. So these are the configuration parameters that needs to be added in. And once you do that, the command to be able to run that remains the same as before. So you just need to do a Quarkus build. You can see right at the bottom, Quarkus OpenShiftDeploy equal to true. The same thing that we ran earlier. So this one is, I mean, of course, as I mentioned, so there are a few more things that I had to do. So I had to create this PostgreSQL instance. So how did I do that?  And so this is all in the sandbox, the developer sandbox. So once you have created your own sandbox, you should be able to do all of this stuff. Here, PostgreSQL is what is the thing that you need to choose. Then you do an instantiate template and then fill in some parameters out here. So you can, for example, put in your own username, password in here and the database name. So for example, I think in our case, we were using Quarkus, so I have to change this. So this is all that needs to be done from on the OpenShift sandbox side. Once you do that, you get an instance that comes up on OpenShift just like this. So you can see that it's up and running out here with all of the changes. I mean, in terms of the username and password and things like that that have been set. And also a config map has been created. So if I can scroll down all the way, okay, I've got too many instances running here. Okay, here it is, so QDemo. So this is the one where I have a few of the config parameters saying that, you know, you pick stuff from here. And so this is where you set up, like for example, how you want to share the user ID password between the postgreen stance and your application.  So once you have done these and these changes out here, you should be able to then deploy the application and it comes up on OpenShift. So if I go back here, I go to topology, this is the one QDemo. So this is the version which is now connected to the DB. Here I'm going to just go back to the same instance. So here you can see that in this particular case, I was putting in the location and not the Twitter ID as I had shown earlier in my local app. So this is on the sandbox and here, the name and the location is being shown. So the last thing I wanted to leave you with was the importance of setting up metrics. So when we are looking at a local demo, for example, okay, I don't have that running here. So let me just start this, sorry, Quarkus Dev. So the, I mean, it's very easy to attach metrics to the application and it's really important that you do because metrics allow us, I think, in the morning, there was a session which talked about observability and the better the observability, the better, you can do lots of things with it, machine learning, right sizing. So one thing that I really wanted to leave you with is that we have, and this is actually a shameless plug for me because this is what I work on. So we have OpenShift Insights. So Red Hat Insights, I don't know if you use, how many of you use that? Any of you who have got, how many of you use OpenShift? Oh, just one hand, okay. So if you have OpenShift, then you also have access, free access to Red Hat Insights. And here, it's a preview feature right now. What we do is to capture the metrics of the application that you are running and then monitor it for a long period of time and give you right sizing recommendations. So for example, currently the application has been, in this particular case, has been deployed with, let's say, 300 millicores, but we are giving a recommendation here that says, you just need 20 millicores and 5.8 for MIB instead of 300 millicores and 512 MB. Why is this important? Because it helps you to do a lot of cost savings. And at the same time, so we provide different kinds of recommendations, whether it is for cost optimized or for performance optimized. Depending on what recommendation you choose, you can apply that configuration and it will give you that kind of a result in terms of this thing. So that's what I wanted to leave you with. So are there any questions? Actually, a really good thing to do. So what I was facing was, in microservices, which does not contain any endpoint, let's say, and it contains a database connections and everything. How do we test microservice like that with using integration testing? Essentially, integration testing is a black box testing. So we need to have an endpoint. Everything is closed.  So in this particular case, of course we have optimized it for it to be able to have an endpoint and where we can pull from that endpoint. So you need to do a little bit more work in your case, where, so you need to have some criteria, right? So whether it's a unit test, so in this particular case, it's a unit test. So you need to figure out, I mean, just like your regular unit testing, whatever it is that you should have some criteria for that, right? Whether when you run the application, maybe it prints something to the log or maybe, you know, it creates a file or some other way to figure out, you know, is it doing what it is supposed to be doing? So you need to create those test cases and then, you know, feed it into this one. So all that this is doing here is to run the test, that's all, right? This test happens to be doing, let's say just a curl of that endpoint and then checking if it matches with what is there. That's pretty much all it is doing. But in your case, I mean, the same framework will call that, you know, the test that you have and you just need to write the appropriate test case for that, that's all I can say for that. I mean, okay, I don't know if you have something right now, maybe we can take that offline, looks like something very specific. And another doubt I have is that this isn't cloud native application, right? So any kind of reflection that Java reflections that we have, runtime class instantiation, those things, is that supported by Corpus?  So you can, dependency injection is, I think you're asking about dependency injection or, yeah, so the thing with Corpus is that, you know, when we look at, I mean, it is doing build time optimization, right? So that it helps you to, while you're running. So the difference between normal Java and Corpus out here is that it is resolving all of the dependencies at build time and, you know, packaging only the relevant stuff so that when you run it, you know, you have everything up and running and it, you know, works like, especially when we're, you know, combined with Graal, for example, you can create a binary in that instance. It's just like a C program or something like that. But in your case, what you're saying is, you want to, you know, inject a new class which may not be available at build time. So there are some things which, you know, I mean, I don't know if I can say that it's 100% supported, but there are examples where we do have that as well. Any other questions? Okay. Not, I think we are done.


Hello, I'm Steve Nunn, President and CEO of the Open Group. Welcome to Toolkit Tuesday, where we highlight the various components and leading experts of the Architects Toolkit, a collated portfolio of the most pertinent technology standards for enterprise architects. During the series, I'll be calling on a number of recognized experts who will bring their particular insights on how to most effectively use the various tools in the Architects Toolkit. We'll have a mix of interviews, panel sessions and pre-recorded presentations along the way. While all standards of the Open Group are designed so they can be adopted independently of one another, the greatest value for an organization can be derived when they're used in unison, the sum of the parts should be greater than the whole. In the Architects Toolkit, we have collated a portfolio of the most pertinent ones for architects, together, all in one place. For most of these tools, certification from the Open Group is also available, so practitioners can demonstrate that they have the skills required and recruiters can take the guesswork out of the recruitment process, all backed up by our Open Badges program. Welcome, everyone. Welcome. Whatever time of day or night it is, wherever you are, I very much appreciate you joining us for Toolkit Tuesday. I think this is number five now, I think. So we've had some great ones so far and today is no exception. We've got a good lineup for you today for the next 30 minutes. I'm not going to take up too much of your time, but I do want to make sure that you get the most out of your experience today. So we're using WebEx as a platform and it helps. If you go to the Layout tab towards the top of your screen, if you click on, you'll see a drop down menu and it will say Names in video and if you click on the automatically hide names when not speaking, you'll get a better view of the people who are actually speaking. So please do that and that will enhance your experience, I hope. And also, just to say, you will be notified when the materials from today are available. So you will get the presentations and the recording will be made available to you and because you've registered, you'll be notified of when that is. And one other thing to mention before we kick off today and that is a proud moment for many people. In two days time, September 30th, the open group is 25 years old and we intend to do a number of things to celebrate that, including at our virtual event next month in October. But I just wanted to mark it since slightly before the day, but we're all excited about that and watch out for what will be a great event and a retrospective next month, a global event, something really, really quite different. So look out for information on that. Talking about digital transformation and digital first. And key to that are the seven levers, as I would say, or levers from North America of digital transformation. So to present on this today, we have, as I say, a long time contributor and supporter of the open group, Mr. Dave Hornford, who is managing partner of Conexium and he leads Conexium's EA capability practice. Dave is based in Canada and works in a variety of industries, including financial services, oil and gas, technology and capital intensive industry. Typically helps clients develop and execute a roadmap to transform. Dave has been involved in the development of the architecture toolkit documents, including practitioners guide and the leaders guide, both of which are now TOGAF series guides. He's the former chair of the open group architecture forum and was a key contributor to the document structure of the TOGAF standard. Dave also serves on the board of trustees of the SEPSA Institute in the security space, an organization that the open group has a long relationship with. So a warm welcome to Toolkit Tuesday for Mr. Dave Hornford. Over to you, Dave. Thank you very much, Steve. With no further ado, I'm going to jump right into seven levers of digital transformation, which is a paper on the key aspects of what you need to do in a digital transformation. We are heavy consumers of the tools that are provided by the open group. And one of the things that we do as a participant is look for the right tool for our job that's at hand. And I got a picture there of two tires being changed. One of them is able to be lifted by a person. And for the 797 pickup truck from Caterpillar, you need 120 ton crane to lift up the body so that you can change a tire. The tire on the 797 probably costs more than two of the cars in the above picture. The concept of changing the tire is identical. The tool you use is different, and it's really important for us as architects or us as practitioners to reach for the right tool. And one of the things my firm does is we look first in the TOGAP standards, the TOGAP guides, the other open group standards. Because if there's something there, we get to move on. If not, then we have to invent it. And I know that my customers care about the destination, not the journey. And they don't really care about that we did a really cool and innovative tool that replicates things that already exist. 7Leavers fits into performing architecture. It fits into changing your organization. It fits into planning where you're going. And you don't reach for a particular tool because you're familiar with it. You don't reach for a particular tool because you're comfortable with it. You reach to a tool because it's useful.  You can use it down lower. It just isn't as powerful of a tool. Staying in a different way. When you transition from providing direction to providing planning to providing execution as you move your way from thinking about where you're going. 7Leavers is also incredibly powerful and helps you understand what needs to change. It helps you understand the sequence of change and the dependencies. It helps you understand groups of changes. One of the things that whenever you adopt or pick up a new tool, you have to understand that that tool is written by someone who was solving a particular problem. The operating manual that comes with a jack for your car is radically different than the operating manual that comes with the 797. And what you need to do the very first time through is absorb the language used by that tool. Not convert it to your language because the people who wrote it, the people who designed it, were intending it to be helpful for a problem. And you need first to understand the problem. When you look at 7Leadippers, there's a core organizing graphic that's square with the two sets of concentric circles. That organizing graphic is designed to show you how the 7Leavers fit together. It highlights that in a digital world, your IT delivery is a hub. IT is at the center of a digital transformation. Now, it's not to say that IT leads it. It's if your IT delivery organization is not firing on all the cylinders that are necessary, you will not be succeeding. Around the outside business process, how do you do your job? How does your company? How does your organization? How does your public agency? How does your government department work? What is your digital product or service? Is it enhancement to an existing physical service? Is it a digital twin? Is it a pure digital service? What's your customer engagement? What's your customer experience? How do you fit into your ecosystem and what's your business model? That's what drives around the hub your digital transformation in the context of your organizational culture and in the context of your strategy. Graphics complicated because we also put numbers on it. We put a sequence one through seven. And those sequences are not an order that you do it. It is building your skill and experience and understanding. If you are not able as an organization to change your business process or understand your business process, leave for one, digital transformation is difficult. If you don't think about your customer experience in the context of your business process, it gets harder. If you don't think about your digital product and the value proposition of what you're offering in the context of your customer engagement, in the context of your business process, you are already in the ditch. So when you didn't go in the ditch on process experience and engagement, you now have to fix probably radically change your IT organization.  And that is a scary novel place for most IT organizations, which is going to drive change in your organizational culture. Leave for five, we're already in the context, is going to enable you new levers in terms of how you move forward and how you engage as a business and how you define a strategy. And interesting, we come back in for lever seven.  You need all the other levers thought about them, preparation about them in order to excel there. The graphic tells you right there, here are two ways seven levers of digital transformation are going to help you through this journey, just from the organizing graphic that we put together. My favorite graphic in the paper is this one, Consequences. I spend a huge amount of time at my job helping people understand consequence. Consequence is what comes from when you do not do a good job. It's where you create risk, uncertainty, and failure. You don't have lever one set, business process. You are flying blind. You don't have lever two set, customer experience.  If you don't have lever three set, value proposition product, not lining up to your value proposition. Lever four, low agility, and imprudent technical decisions. Your culture is dependent on your ability to exercise change. The worst thing you want is highly skilled, incompetent people who cannot move yourself forward. Strategy, are you tone deaf? Are you able to look at your world, at your reality, and define the path forward? And last, your ecosystem. Are you losing synergy by partnering across your ecosystem? Given that, let's walk our way through the seven levers. Got all seven? What's the purpose of each of them? Let's walk our way through them. First, business process. First, business process. You don't have search and rescue. You undertake a business process change. Your business is changing, and you can all of a sudden start to fail. And what we're chasing here, is understanding the future. Understanding where you're going, and understanding what you are trying to accomplish, so that you can move forward, so that you can build the internal approach that lines up, lever two, your customer experience. You want a happy customer. Other day, I was trying to buy something online. And it was a fairly expensive thing, and you couldn't just store it. You had to talk to them. So I clicked Chatbot. And the Chatbot came up and asked me 11 questions to tell me that although it was 11 p.m., 11 a.m. Pacific time, the store hours were only 8 a.m. to 3 p.m. Pacific time. So I'm in their store hours, and it says, I'm sorry, you're calling outside of store hours. What's that customer experience? I even got the product. And I'm already having a negative experience. I'm already on the left of that graphic, not on the right. Value proposition. Who's your target customer? What is it that you are trying to deliver?  What are you doing for them? What gain are you providing? What pain are you removing? Are you building a digital twin? Are you building a digitization? How is that lined up to a value proposition? Not the cool thing that you could do with technology. What is the cool thing that delivers value to a customer? IT delivery. One of the most common areas we run into is working on digital transformation work, is having to rebuild IT delivery to be in the forefront. IT is so used to being in the background and having a lot of excuses for substandard behavior. When you are the product, when you are the sales channel, you don't have a choice but to excel. And that changes dramatically IT delivery. Now I want to be really clear, a lot of people read this and go, whoa, whoa, whoa, why is IT at the center? IT is at the center because a digital product is digitally delivered, which means it's delivered by IT. And if they are not prepared to compete head to head, you are hurt. Your culture. Your culture is your brand. Your ability to change, your ability as an organization, thinking about continuous learning. The moment you enter the digital world, you are going to tighten your cycle time. This isn't, we are going to invent a product, we are going to design a factory, we are going to do this, we are going to do this, and all of a sudden we have a 3, 4, 5 year launch window. Digital products come and go. Digital products are continuously refined. Digital products have new challenges. Years ago, Y2K was working with a telephone company. And the Y2K office wanted to, you know, we have to lock all our IT systems down. And the mobile guy said, yeah, no problem. We agreed to a lockdown of all of our customer facing systems and all of our brand products. On December 31st at noon. Because if there is a change in the market, we will react at any point in here because we are head to head in consumer products. We will not change. And that is our culture. Are you a customer service organization? Are you focused on where you need to go? Are you able to continuously improve? Number six, strategy. My favorite thing is where I spend most of my time is helping people develop that roadmap, develop that strategy on where we are going. And a strategy is all about act. It is all about action to change things. One of my favorite quotes from a TV show, House, Dr. House says, people think time changes everything. Well, in reality, time changes nothing. People change things by doing an action. What are the changes you need? Are you prepared to make that coherent set of changes through your organization? When you nail this, you have good ability to execute. You have a thoughtful sequence to execute. You understand what are your underpinnings. And it is not going, oh, we could develop a digital product as you have seen through this business process. What is your customer experience? What is your value profit? What is your value proposition? You do not know those things. You are dead on the gate. Or you even get to where we are going to go and how we are going to execute. Because digital transformation is about changing your organization fundamentally. Why it has got the word transformation. And I know right now it is cool. And the word digital gets slapped on everything. The word transformation gets changed on everything. Let us move ourselves forward so that we are in a position to excel. Last, your ecosystem. Create synergy. Are you building an ecosystem that others play in? Or are you playing in an ecosystem that others are dominating? Both are valid. A lot of the stuff that we talk about is like, oh, you got to have a platform. Oh, maybe.  Or are you going to find a niche that you can compete in? Are you going to find the partners who deliver? Because one of the natures of digital is it is so much easier to string together a value chain. Of other participants in your industry instead of having to do everything yourself. That plays back to culture. Are you prepared to continuously innovate? And are you prepared to partner? You don't have that. You don't get to build a good ecosystem to move yourself forward so that you can cultivate the approach. That's successful. What was enough? This is all about the right tool. This is all about using the right tool. This is my favorite picture because I do a lot of backpacking and camping and things. I have a titanium magnesium flint and steel. It is able to spark and light something up no matter what. And it is fundamentally no different in concept from what the very first humans used to light a fire. It generated a spark. Generate a spark in your organization. Use the tools in the toolkit. Use seven levers to frame your thinking. Use seven levers to understand this is the core challenge I have to hit head on. Build your approach to change. Focus your attention on the hard bit. Focus your attention on the challenge. There's my quick summary introduction to seven levers. It's one of the shortest things I've ever written. Compared to like leaders guide which is I think a trillion pages. So it's far more approachable but it's designed to give you a conceptual structure to think. And I believe at this point Steve you have some hard questions for me. Well we'll see Dave thank you very much for that. That was a real whistle stop version of what is a great document and I know I've seen a longer version of a presentation in the past too but really valuable stuff and right on message for toolkit Tuesday. It's all about the right tool to join us. So I'm going to ask you some questions but I'm going to make it even harder for you because joining us for the questions is my colleague Chris Ford who is CEO of the Association of Enterprise Architects but also VP of Enterprise Architecture in the open group as well as his responsibility as general manager for Asia Pacific. So welcome Chris. Before I dive in for questions on Dave I'll surprise Chris and ask him one. The reason we asked you here today was you actually did a toolkit Tuesday presentation recently and you called out this paper The Seven Leaves of Digital Transformation as a very significant document. Why that one? Well you know it's a great question. I just I'm not the only person that thinks that way. I'll give you by example there is a fusion standard in China for a technical committee 573 which is integrating all of the national standards around digital transformation and they outright referenced the document that we're talking about today as a seminal piece of work to guide their thinking about what approach might be taken for China's digital transformation. So the reason that I think that the document is valuable and I call it out on a frequent basis is that we publish a lot of standards that are as Dave said earlier there are a lot of pages you know this document I think if you remove the front matter and the reference material at the back end is about 21 pages you can get through it in 15 or 20 minutes and get a lot of value out of it. So that's the fundamental reason it's a short read there's some very significant material in it and it's quick time to value from a concept standpoint in my view. Great example of less is more. Yeah absolutely absolutely. Okay Dave so one of the things that I always remember when I go back and look at the document and consider it is you stress that this is about taking control and you can't skip a lever. You have to do them all. Really?  No if you get to skip customer experience and value prop all day long because it really doesn't matter. And there's no point at all in worrying about how your organization does business so processes you can you can toss that under the bus. Organizational culture no having a backwards looking organization that has dreams of its prior glory go for it. Planning your action and your transformation skip the strategy you're good to go and last of all you really want to continue with an IT organization that can't meet deliverables and is worried about a raft of non-customer facing things. So you get to skip all of them. All you have to do is choose to live with the consequence. All about the consequences. So I'll take that as a yes you have to do all of them Steve. Okay so I'm about to do all of them. What can I expect to be the hardest ones do you think Dave? Which in your experience do people struggle with most? It depends on your organization. It depends on where you are. It depends on are you ahead of the curve or are you being is your industry being transformed? As a rule a great number of IT people have a lot of difficulty with the with the IT delivery as the hub because they aren't prepared for understanding that they're going to be front and center. I remember years ago working with a very large e-commerce player and their fundamental rule is no developer can close the store. I remember talking to a guy who was working on a transformation at a global financial services player who said we have been in business for 125 years. We will be in business for the next 125 years. We will knowingly pass on short term things to move ourselves forward. So that organization would have very different challenges than somebody who is a small organization. And all of the levers exist and you need to approach them all but you need to look at your organization and where you've got difficulty or where you have the challenge to move forward. What is the barrier to your organization being excellent? Okay, another question. Let me start with you, Chris. What do you think is the single most important issue in digital transformation? Well, Dave just answered that in the sense that it depends. I would not argumentatively disagree with him because we have a lot of discussions about this sort of thing. I would say that in the end culture eats strategy for breakfast. So the soft stuff, so to speak, that you need to get into in order to make this type of thing work is really, really important. And that's a very complex issue. There's a question in the chat channel asking about what size of organization, minimum size is important for this paper. Well, actually all of them are. If you look at the digital professional body of knowledge material, it has a step level model going up from founder up to an enduring enterprise level. And it makes heavy use of the concepts from this paper as well. The issues that we're talking about here are applicable to a foundational entrepreneurial enterprise as they are to the size of enterprises that Dave was just referencing. This is fundamentally what you need to do to operate a business, whatever size the business is. The scale of the problems may be different, but the nature of the problem is not necessarily different. So I'd answer it a different way, Steve. You are CEO of the Open Group. Your organization spans the globe and is shockingly small for what it does. You don't have very many staff. Which one of those levers is the most important? You are undertaking a digital transformation. You are changing how you do conferences. You are changing how people engage with the Open Group. You are changing how the members develop and collaborate. Which one is an important? Yeah. Yeah. That's a good way of coming back to the previous question. They all are. Yeah. Can't miss them. Okay. Well, we are running short of time, but I do want to take at least at least one more question. And I'm looking at the chat as well. There's some things coming in which I probably won't be able to get to. I'll try and build it into one, but can you give any examples, Dave, of where you've used the seven levers approach or where you've heard of it being used successfully and maybe mention some of the metrics that you've seen used for whether it's working or not? One of the most important metrics that we use is the ability of the organization to change. How hard is it to change? Digital transformation means that you are there is no difference in a digital transformation to the very first industrial revolution transformations. All we're doing is tightening our time cycle. Right. And I've been spending a lot of time on the projects that we do looking at the ability of an organization to change. The ability to enter or exit a market. The ability to enter or exit a service. How quickly can you do that? The enterprise agility. And that tends to be the most significant one. And the other one that's in the chat that I wanted to comment on is customer experience is incredibly difficult for the public service. The idea that you don't need to engage and you and Bish were talking about the pandemic while I live in Canada, we've been going through a whole thing on registering for vaccines and they have had to release multiple platforms for us to register on because of the difficulty of the customer experience. We're first trying to register my 96-year-old dad and the only way you could do it was online. My sister went over to help. He didn't have a computer. Took her smartphone. User interface. My sister and my dad couldn't figure it out. They couldn't get him registered. One of the common systems in customer experience is those simple things about are you even able to deliver your service if you don't have customer engagement and customer service? And it is as applicable to the public sector as it is to anybody else. Absolutely. In fact, as you know, Dave, because you've been very involved, we've got a work group in the Open Group, the government EA work group, trying to address that issue and help the public sector catch up in that sense. So great stuff, gentlemen. We're going to have to leave it there in order to respect people's time. We've got people joining us from all over the world, including Chris here in Shanghai and you, Dave in Canada. So thank you both for joining us today and take care and keep safe. Thank you very much. Thank you. So before we end today, just a quick mention of what's going on in two weeks' time. October 12th, the next Toolkit Tuesday, we are going to have an Ask the Experts session. So more time for questions, no main presentation, basically just questions of some of the experts that those of you who've been joining us on Toolkit Tuesdays will be familiar with now, Terry Blevins of EnterpriseWise LLC, Chris Ford, you've just seen, Chris Frost of Fujitsu, Paul Holman from IBM and another of my colleagues Andrew Josie from the Open Group who will be known to many of you, with a specialism in his case and standards and certification. So they will be a panel in two weeks' time for you to ask questions of. So please join us. It's a great opportunity to get some questions asked and answered. And please join us in two weeks' time. In the meantime, wherever you are, please keep safe and well. And thank you for joining us today on Toolkit Tuesday.


Well, hi and welcome everyone to the session. What's new in Gradualizer? Gradually typing in Elixir and Erlang with Radek Shintishan. We're really glad you're here with us, Radek, and without any further ado, over to you, Radek. Thank you, thanks for having me. So I will talk about what's new in Gradualizer and about gradually typing Erlang and Elixir. Okay, so what's the agenda going to look like? First, I will introduce myself. Then I will talk a little bit about what Gradual typing is and how it fits in the picture of strong typing, weak typing, dynamic, and static. Then I will talk about the approaches to gradually typing Erlang and Elixir. About what's new and actually since when it's new because the tools I'm going to talk about are still in development, so they change quite frequently. But the meat of the presentation is going to be the demo or two demos, one with Elixir and Gradient and the other one with Gradualizer and the Erlang language server. And then I will finish with some practical tips. And I'm happy to answer some questions throughout the session and we can have a bit longer discussion at the end. So let me introduce myself. I'm Radek Shanshushen. You can find me under the Irish handle or nickname on GitHub, Medium, or Twitter. I'm a tech leader at Erlang Solutions, specifically the crack of Office for Erlang Solutions. I have been working at the company for almost 11 years now. I'm a static type system enthesiast, and I'm saying enthesiast because I don't have professional background developing type systems or academic schooling in that. But in general I have a master of science, computer science background, so I think it's a good foundation to deal with these topics. And I'm contributing to Gradualizer as a core team member and I'm also co-creator of Gradient, which is an Elixir frontend to Gradualizer. I also believe that sleek and good quality docs can make a programming language community and ecosystem easier to approach, easier to start learning and start contributing. And that's why I co-authored Erlang Enhanced Proposal 48 and also implemented that as part of E-Doc, which is part of Erlang LDP24. And this was the groundwork for using the Elixir X-Doc sleek and modern docs for Erlang projects. And I'm also an instant messaging expert, an XMPP engineer, I'm an XMPP server core team member, who I'm recently not very active on that, on that front. And in general I'm an Erlang and Elixir programmer professionally. So more on the topic of this talk, what is Gradual typing? Let's start with this simple diagram. And obviously it might be a bit biased, but the point here is not to classify and argue about which language should be in each, in which part of the diagram, but to think about how we can classify or what are the angles or the axis on which we can classify programming languages. So let's think of two axes, weak typing and strong typing being one of them and dynamic versus static in the other one. So for some examples, how can a strong type system look like? A perfect example of that is OCaml, which has a very strong type system, which is very explicit but sometimes clunky. So examples of statically type programming languages are Haskell, OCaml, Fsharp, Scala, to some extent C++. And what's on the other end of this axis? So if we have static, then we also have dynamic. So how do these programs differ? Programming languages differ. So in this case, a program does not have type annotations, but if it's a strongly typed language, then data has well-defined types. So it's impossible to do invalid operations. But if it's impossible, there has to be a check done at some point. And in these dynamically typed languages, this check is done at runtime. So just before an operation is carried out, it's checked, whether it's a legal operation or not a legal one. So for example, in languages like this, it's not possible to add an integer in a string because this results in a runtime exception being thrown. And this might happen ideally when we test the program, but sometimes it might happen as flight as production, which is pretty bad. So whatever pros of these languages, they are usually more flexible because there are no type checks, there are no compile time checks. So we can just pass that around where we need it. And this leads to a flatter learning curve. But there are also some disadvantages to this. For example, it may be harder to navigate code because we sometimes deep in some code, we are not really sure what code we, sorry, what data we work with. So are these numbers, strings, some hash maps, or more complex data structures? So the APIs are less defined. We also have to test such programs way more and achieve very high coverage to have confidence in the logic of the program. And there's also performance penalty because the checks are done at runtime, they slow down the program a little bit. And examples of such languages are Erlang, Elixir, Python, JavaScript, or PHP in Lua and more. So let's see an example of how a dynamically checked program language looks like. Here we have a snippet of Python where we define a lambda function or a closure which accepts a parameter. And we immediately apply number three to that closure. And because this closure just adds the parameter to a constant two, this evaluates the five. But if we try to apply a string value, so the string a, we get an error thrown at runtime and this is how the error is reported. That type error type must be string not int. In the case of a statically typed program language like Haskell, when we define something similar, so a lambda function which accepts the parameter a and adds this parameter a to a string with a number two. If we try to apply an integer to that function, this program simply will not compile and we will get a very specific error. So it's not possible to run it. There is no space for runtime exceptions. We'll get this feedback at compile time so way, way earlier. There's no risk of production issues. So we see some benefits of both approaches, dynamic and static. We also see some deficiencies of both approaches. So why not try merging both or taking the best of both of these? And this actually has been tried multiple times in programming language history for different programming languages and also using different theoretical methods. So gradual typing is one of these approaches but we can also find the notion of optional typing in literature which was not as strictly defined formally but the practical implementations of gradual typing defined by Jeremy Seek and Waleed Taha are for example TypeScript and Flow for JavaScript. MyPy or Python or TypeTracket are probably the best or the airlist example of gradual typing in practice. Hack from Facebook for PHP and also a gradualizer for along and gradient for now gradient for Elixir. And when we talk about optional typing it also requires underlining that there is a well-known and quite widely practiced use of type specs which were popularized by a dialyzer developed by Tobias Lindel and Kostas Saganas. And thanks to that our programs which used to look like on this slide now quite often look more like on this slide. So we have the type information, we have the better defined APIs but could we use these types and function specifications more effectively? So the advantages of gradual typing are that we can move between a completely dynamic program so like this one to a statically type check program with like this one but not do it all in one go so we don't have to specify the entire program to reap the benefits of using the type checker. So we can add the types and specs as needed for example as a team app skills and learns new techniques or as project grows more people are added to the team or it matures and there are more and more APIs and we want to make them easier to navigate and also when quality becomes more and more important it's not a prototype or not a prototype anymore it has to actually work under a lot of different circumstances in production. So another aspect of gradual typing is that some parts of the program are checked statically the ones that have type specs the rest is still checked dynamically at runtime and it can benefit from the let it crash philosophy or the supervision trees restarting parts of the program etc etc so we go we do away with the all or nothing approach that it's either all type checked and annotated or it's none and it might all crash if we don't test extensively okay so now that we know a little bit about the approach in theory we can have a look at the practical implementation for Erlang and this is Gradualizer this is a Gradual type checker created by EOS of Spanningson and the first introduced at Codebeam Stockholm and the assumptions are that we can start with writing dynamic Erlang as usual and that message passing will always be dynamically typed so Gradualizer does not use any mechanisms to type check this part of our programs static typing is opt-in so it only happens when we add a type spec to a particular function without a type spec there is no check happening so we can add the specs only where we feel it's a prep right and then we just run the type checker and profit from the box code and from the feedback we get from it all that before runtime and in general the tool is still experimental but it's constantly improving and on the right hand side we have the list of top contributors to the project a little bit about the theoretical underpinnings so there is no global type inference in Gradualizer but there is a mechanism called bidirectional typing used which relies or incorporates a limited local type inference and the amount of type inference can be controlled with the infer flag passed on the command line there is also pattern type inference and there is a limited type refinement based on pattern matches or actually mismatches and guards and here is an example of type checking a very simple Erlang program at Gradualizer so we define a simple function taking two integer parameters that just adds them we also define a print function which doesn't have a spec which is fine because it's gradual typing we don't have to add a spec everywhere and we define a test function that misapplies the add function to two different arguments because one of them is not an integer and then we run the type checker on this module and we immediately get feedback that the string on line 8 is expected to have type integer but it has type string and the error is highlighted or underlined so it's very similar to the Haskell example and I would like to introduce Gradient which aims to do something very similar for Elixir basically it's a frontend to Gradualizer which allows to use the tool for Elixir programs and kind of it's the glue between the Elixir code and the Erlang syntax tree that's actually produced by the Elixir compiler and also is used by Gradualizer to do its type checking but Gradient is not just that it's also a little bit of macro magic to provide more type checked or a bit better type checked frameworks all the assumptions are very similar to Gradualizers and the tool is created mostly by me and Tromek Vojtasik a colleague from the Krakow office for solutions and it's also experimental but it's constantly improving and here is an example of using Gradient with some Elixir code the code is exactly the same as with Erlang so we have an add function taking 10 teachers we run a mixed task gradient and we get the feedback that's the bit expression line 7 is expected to have a integer and the error is underlined in red so that's it for the introduction of the tools now I would like to very quickly go over the features that were added since the last approximately half a year so it's exhaustiveness checking of non-trivial types it's type checking of maps and therefore elixirs tracks it's exhaustiveness checking of map variants so this is connected with the first point but it was quite a different chunk of development it's property based testing of the type checker to well squash as many bags as possible and make it robust which also led to the discovery of some infinite loops and fixing them there is also a gradualizer diagnostic for the Erlang language server which makes a gradualizer feedback immediately available in the editor of your choice and many many many bag fixes so I won't go over all of this in detail at this point because I really wanted to focus more on the live demo which I will switch to now are there any questions at this point I guess there is nothing in the Q&A box okay thank you so I hope you can see the screen clearly and specifically if the font is big enough if not please let me know so on the left hand side we have an example elixir module and let's try type checking it okay so I ran gradient type check file on this module and it returned okay so it means that the code type checks properly so this code describes a gen server which is an implementation of simple server handing two kinds of messages one of them is an eco request so the server should receive a message and then just echo it back to the sender and the other request is a hello request so the server should just receive a request of this type and then print the name or well the payload of this request but it doesn't send anything back and the idea here is to make this message passing interface not only the function interface but also the message passing interface explicit so how can we do it how can we leverage the type check or type system to do it we define the message type which is a union or some type of these two aforementioned requests and let's see if the type checker and this definition can guide us somehow on working on this code so for example we know that the type checks at this point but what if we change this definition to something different let's say I remove the hello request and let's type check again right now and we get the error that the clause on line 63 cannot be reached let's check line 63 and we see that this is the implementation of handlefall the gen server behavior callback for a tag tuple with the hello tag and a name so okay we declared that the type of our handled messages is just the echo request but here we have code for a different request so okay if that code is never going to be used so let's comment it out and type check now okay it's good we fixed the bug so let's try again with the expanded version of this type so this is exactly the same as the first definition but here we just expand the types to their definitions instead of using references to ring those types and let's type check at this point and we get the warning that not exhaustive patterns on line 58 and the example value is hello so let's jump to line 58 and indeed here is the implementation of the handlefall function for the echo request but we are missing the implementation for the hello request which is now part of the declared messaging API so okay let's fix that and bring this code back and type check now and back to normal we declared we handle to different requests and we have to handle them because otherwise we get an error reported so how else do we use this mechanism like let's try what happens when I do a silly mistake like I do echo rex instead of correct time and let's run the type checker now so we get the warning that pattern echo rex on line 58 doesn't have the type message and indeed because type message defines an echo rex type so let's fix that type check one more time so what do we get we get dead code detection if we declare in the message less types of requests that the implementation does we get warnings about missing code and we get warnings about silly typos and issues when we implement a handler for a message that doesn't exist so far we get it seems pretty useful so let's go to the top of this module and look at the echo API function this function is exported to the users of the module and of the server so so far we looked at how type checker can help us when we implement the logic of the server but can it also help us on the side of the server process so before we actually make the call to the server and yes it can in some way let's see how so we know that to call the server we use gen server call let's check functions documentation but we know that this function returns a value of type term the most general value that exists it can be anything there is no information about that so for example if we wanted to pattern match on this value because we know that an echo response will be something different than a hello response or that there might be different echo responses based on the state of the server we might want to pattern match on that and do something with the response afterwards but since the gen server call returns a type sorry a term of type of this type of a general one the type checker cannot help us so we have to we have to help the type checker help us in this pattern and we do it by using the annotate type macro where we just do the call as usual and then we also pass information about the return type of this call and thanks to this we reap the benefits of the type checker so for example let's try what happens when I do a silly mistake like this we get the feedback similar to the previous one that's the pattern echo that on line 30 doesn't have the expected type so that's nice let's fix that check again back to normal so this syntax might look a bit heavy so we can also do it like this to make it more similar to ordinary elixir so the annotation can come last and it's probably being piped into it or we can complete to get rid of the explicit annotation and just use an auxiliary function like this for the same effect so let's see what happens when we do it like this and let's actually introduce a bot okay this worked so what's the difference and why do we even need it so another type doesn't do anything at runtime it's a no-op it just takes the value of that we passed to it and it returns it back but it embeds this type information into the abstract syntax tree of the compile module so the type checker can use it for its reasoning about this base expression and if we don't want to use the annotation but we are more happy about the auxiliary function this information is simply passed in the spec of this auxiliary function so we need to pass this to the type checker because otherwise it just won't know the type of this value of this response so sorry to interrupt just letting you know there's about 10 minutes remaining thank you do we have any questions at this point yes we do have two questions in the library books okay so I'll read the first one so we get a question from sorry if I pronounce it wrong but some of the gradual type checkers a little smoother gradual typing so just having an option such as minus minus strict what do you think about this approach so I'm not sure what the meaning of this option would be but I think that one option that's pretty similar in Gradualizer is the infer option it's a bit more strict in the default mode the infer option it will try to tell the type of more more terms more things in our program so I think that it might be a little bit related but maybe not exactly the same thing okay thank you for the question so before answering more questions I would like to go to the next part of the demo to stage 2 and here I would like to ask the question like how can we use the type checker to do a little bit more how else can it help us and one of the ideas is that in the airline virtual machine or in the electric runtime we have a lot of concurrent processes we have multiple servers running but there are different kinds of servers like one of them accepts different messages than another one and one of the possible mistakes is that we send a message of a certain type to a server which just or a process which doesn't handle it and it will lead to a bug in production it will lead to a bug in runtime or even a crash at runtime so let's try to run an example and see how it works okay sorry I was to run the example and I run the type checker so I run some code the code of a test and now I will comment a line that I think will lead to an error and then I'll run it again and then we'll go over the code of this test and yes something else is happening like it seems that this got blocked and yeah after a while we got a runtime error that gen server call timed out so well this is definitely not something we like to happen in production so let's look at the code to see why it's happened so we create two types of processes one is of our particular server type so we created with server starting and the other is just a random process that does something completely different than our particular server and when we use the server API to call our server process it responds with with the expected things so it just returns the payload but if we use the server API to call a random process like just in some arbitrary process well we see what happened on the right hand side the server sorry the request timed out because the server cannot handle it and we would like to avoid it so let's see what happens when we run the type checker on this code right now and we get a warming the variable on line 103 is expected to have type T not just the arbitrary or the general type PID and so we get feedback sorry we cannot use the server API with any process with any PID we have to pass a PID of this particular type and how is it how does the type checker know that so when we jump to the top of the server definition we define a type T which is actually equivalent to a PID but it exists as its own type a type of this particular server and then all the API functions accept only this type T or return this type T instead of a PID so when we start link we return okay T or already started T the eco function only accepts the type T the auxiliary function called eco also only does that all the rest of this example is the same as the previous one but we see that thanks to explicitly defining the type for our process we can avoid the API of this of the server being misused with PIDs of a different process so another win we know this we type check the code and we know upfront before running it that we misuse the APIs and I will quickly jump back to the next example without asking for questions at this time because one of the things that Robert Burding one of the creators of Erlang pointed out when I was showing this demo to him that we could actually generate these auxiliary functions and it was obvious immediately obvious to him but it took me a while to figure out how to do it but indeed it's possible so we don't have to implement this function ourselves we can use some macro magic that's provided by gradient to generate them this function is actually generated to be exactly the same as this example here so we don't have to uncomment this code for our server to run and to type check see if it type checks and indeed we got an okay so how is it possible that this code is generated and is there anything else that we can benefit from so it can be generated because instead of using a gen server reply we use type server reply and as in the previous example we used the type of the response in the annotation or in the auxiliary functions spec here we use type server reply and we pass the type of the response so we have more locality because this type is type of this expression so it's less possible that we make a mistake even the value and the type are on the same line and moreover thanks to using the same macro or these two things being arguments of the same macro this is it's not possible to actually do a typo or provide an invalid value a value that's not of this type here because if we do it we will get a warning that the variable line 71 is expected to have a type contract echo response but it has type echo sz and we get it highlighted so not only we can generate the auxiliary function but we also get type checking on the response so let's fix it and that's it for this example I have one more thing that I would like to show and this time we will jump from the elixir world to the Erlang world and here I would like to show the integration between the gradualizer running the background and Erlang language server which gives us feedback and this is a different code I won't go into the details about what this code implements but I will run the type checker on it and see if I can get okay so there is definitely some errors in this code so let's just browse this and see how the integration with Erlang language server works okay so for example here we get a warning that the pattern of R doesn't have the type abs something something so let's scroll more that's the operator plus as expected to have a different type okay so that's how the feedback is displayed in the editor and again we see the information the pattern of R does not have the type something something so okay there seems to be a repetitive warning about the pattern of R so let's search for this pattern in this code like I okay we found the definition of type term which has quite a lot of variants like probably 15 or maybe in 20 of them and one of them is commented out so okay let's go back to one of these reported errors and comment this out and yeah we fixed the error at least we think so because it's satisfying but now when we change the type definition and go back to that place we get a different error that in the place where we first tried to fix the issue we got feedback that there are non-exhaustive patterns that pattern of R is never matched so we see how we see live feedback about how our types of representation mismatches if it's the case and it's quite easy for it to mismatch if we operate on types that have like 20 different variants so live feedback in Gradualizer also seems to be from Gradualizer and Editor also seems to be pretty useful and I like to stop demoing now and go back to the last slide with a few closing remarks like I think it's worth to leverage the tools as much as possible so use the Erlang language server for live feedback in the editor use the compiler options like one missing spec and one missing spec all because the more specs we have the bigger confidence in the code we can get there is no elixir language server integration available yet for gradient but fingers crossed we're going to get there and we could see how using these tools leveraging these tools we could do a bit more type driven development by describing or domain with data types writing them a limitation letting the type check refine bugs and not necessarily test everything even the trivial parts of the program and it also helps us with aggressive refactoring when once we have the domain described with types but we have to extend this description and we have to modify the type definitions or a function spec we just run the type checker and let it figure out what else has to change in the program to match these changes in the domain model however the tools are still a bit experimental so if there is suspicious code or suspicious warnings or some warning is not clear it's worth writing a test and if you happen to find any issues like this please do report them on the respective project sites on github so gradualizer or gradient and that's it thanks for joining thank you so much for joining us everyone and thank you Radhik for sharing your experience with us today