 So, I'm going to talk to you a little bit outside project I've been working on for last three years. It's called RIDDL, it's an acronym. But before we get into that, I started thinking about this years ago when Kent Beck in 2004 wrote about the changes of cost, you know, changes cost exponentially more to fix later in the software development life cycle. I realized that there's two kinds of changes, internal and external. We can't really do anything about the external changes, right? Laws change, ergonomics, competitors, they're going to do what they do and we have to adapt in our software. So those kind of changes, there's really nothing we can do about it, it's unforeseen. But the internal ones we can do something about. So we've got requirements, stakeholders, changes, they're mind about things, design defects, code defects, resiliency defects. We want to shift left this whole problem because the further left we can get back to the conceptual area the less it's going to cost to have those kind of issues occur, changes occur, defects occur. So that should be old news to everybody but this is where I started thinking about it and riddle resulted from me thinking about this. Okay, so what is riddle? So it's an acronym, stands for reactive interface with definition, domain definition language. Sometimes I change the width to four, anyways, the main words are there. It's something I came up with at the very beginning and it stuck. I may rename it someday but it seems to be okay. So it's a specification language, not a programming language. So it's not Turing complete and it has an logo and it's aimed at these kind of things. In other words, the kinds of systems that this audience builds and interacts with. So they have to be large, distributed, concurrent, data-flying, reactive. The main thing that I've built is a compiler. So the compiler has three phases, so it parses, in other words it checks for syntactical errors in the input. It validates, make sure that the model that you've created in the riddle language is correct and doesn't have any missing things, it also will comment on your style. And then finally it translates. So this is where we take the valid AST that has been compiled through parsing and validating and it will translate it into anything you want. We have several things that it already does but you can program it to do other things too. So riddle was influenced by a number of things, starting off with, of course, reactive. The reactive manifesto has been important in my life for the last ten years and it's designed around those concepts that Mary was talking about earlier. It's also heavily influenced by domain-driven design, notions of entities and bounded contexts and various other things that are in that book and others related to it, heavily influenced there. It was also influenced by ACCA, reactive microservices, data streaming, etc. The whole notion of design as code came about when I discovered Mermaid which is diagrammed by code. I thought that was a very powerful technique and so I wanted to do design that way as well. The C4 model that's come out recently, the containment hierarchy idea is present in riddle. There are requirements that can be specified as Gherkin test specs and I've adopted the Gherkin language right into riddle because it's just perfect for doing those kind of acceptance criteria things. Agile user stories, of course, I have to connect it back to the end user and of course the nature of the systems that we're talking about here, we need the cap there. There are other influences but these are the big eight. What reactive does, a riddle does is this, so it can validate your model with the compiler and then it can generate input for Hugo. Hugo is a static site generator and then Hugo can process that into a static site. The interesting part is what are we going to do with it next? One of the things we want to do is create Kubernetes deployment descriptors. So we have a description in riddle of the system, an entire system and we can use that information to generate deployment descriptors. Another thing is making diagrams, this is a part I'm working on right now. I dove into D3 a few months ago, thought I could just do it all by myself then I realized I needed to learn D3 because it's a bit complicated. It's a great library and I'm starting to create sort of containment hierarchy kinds of diagrams that are interactive that you can explore with it. Not quite done yet but that'll come out probably within the next year. Also making API specs, so there's implied APIs within the domain model and so I plan to actually crank out open API specs from that. Of course Jonas just talked about Kalex and that seems to be one of the great targets for what we can generate from a riddle specification. It's not going to generate everything, it's not going to generate the business logic. Again, it's not during complete language but it can generate all the infrastructural stuff, in other words the GRPC definitions of services that Kalex uses and it becomes sort of a fill-in-the-blanks approach to code generation. I'm going to make a template that you can subclass or trait that you can subclass and go from there and then also by popular request by this gentleman here making a software catalog with Backstage. These are the ones that we foresee, there's probably many more that we can do. It's like once you've got a validated model you can pretty much write some code to generate whatever you want. There's many more things we could do. So I want you to just sort of with that preamble in mind, just do some dreaming with me for a moment, wouldn't it be nice if we had a comprehensive design model that was written in code and that design model focused your team members into a common understanding of the design as it evolves and that's one of the key design principles here is that it's not just the static model you create once, it's part of the development process. So it stays up to date and it generates the infrastructural code so that when you go to compile that after a change, it won't compile and you'll be told, you'll be, you know, you'll be clued in by the compiler what needs to be changed. But really the main thing here is getting everybody on the same page. The fact that we can generate a Hugo static website and do it in about a minute from a fairly complex model allows that website to just stay fresh all the time. That design model never diverged from the system code. Throughout my career, you know, the design and the documentation gets written sort of upfront and then it becomes irrelevant because we go off and code and things diverge. But by bringing it back into the software development process that stays fresh and relevant to the code that's actually operating. Design defects were detected earlier in the project. I'm really sure they had a sip of water before I started. Going all the way back to Kent Beck's argument that the sooner we discover the effects in the design or the code or anything, the better it is for the process. The project is less expensive. Design model is used to generate many things, saving time and money. So my goal here is not to make this generate all the code. It's to generate all the boring code, all that infrastructural stuff, all that complexity stuff that Jonas was talking about. That should just be generated. Design misunderstandings are nearly eliminated. It's consequent of keeping everybody on the same page. All this was done for distributed reactive systems. And it is, it's really focused on that. This isn't going to design an app for you. It doesn't have a notion of even color. But it's an open source project that's aimed at distributed reactive systems. Project costs were lowered because of all of the foregoing. So this is really, remember at the beginning, I was telling you this, I was looking at these mounting costs as you go through a software development lifecycle. And this was all aimed at reducing cost. And I wish I had time to show you the code, but I don't. If you want to know more, I can demo this out in the hall there. So come by our booth and we'll write out the doors here. If you want to know more, just get your phone out, click on it, or take a picture of the QR code. It'll take you to a page where all these links are there. But there's documentation, there's the source code, there's discussions on GitHub. There's an example of an internal project that we're starting to build. And if you want to email me to use this or get trained on it, I'm happy to talk to you about that. And I'll take a few questions and answers. Or I'll take a few questions and I'll try to provide answers if there are any. Yes. So the question is, is this a DSL on top of Gherkin? So Gherkin's sort of one fundamental but small aspect of the language. And yes, it's very much a DSL. And I can show you this if you just come by the booth. You'll get to see it. It was just hard to coordinate doing a live code with this projection system.