Video details

React London - August 2020


Ruben Casas, Talia Nassi & Sam Larsen-Disney

During React London, Ruben Casas talked about microfrontends, followed by Talia Nassi presentation about setting up feature flags with React. And finally, Sam Larsen-Disney used React to replace PowerPoint with a more flexible tool. Our second virtual meet-up took place on August 18th with talks from Ruben Casas (American Express), Talia Nassi ( and Sam Larsen-Disney (American Express)
For more information on all things React London visit:
If you are interested in speaking at our next meetup email us at [email protected]
Red Badger jobs - [email protected]


Hey, hey, everyone, can everyone hear me? Also great, I hope you liked my very professional fade down of the music then. OK, welcome to React London's August Meetup. So it's been a couple of months since our last one, but we've managed to gather together three amazing speakers from across the globe who are ready to talk to you about all things and react if you want to talk about what we're doing tonight on Twitter and things like that and feel free to use the rest under the hashtag. If you are so inspired that you want to speak at the next meetup, then please get in contact at Hello London. If you want to read the kind of contacts, just knowing how to behave and how not to be an idiot and feel free to read the code of conduct. And if you're interested in a job, then please contact jobs at Red Badger dot com. I forgot to introduce myself. I'm Tim. I am someone who works at Red Badger and we organize the Clinton White House. And of course we do this meetup out of the kindness of our hearts, but more importantly because we want to recruit people. So if you are someone who could possibly follow the engineering lead role, then apply. And so we're looking for an engineering lead to join our digital product delivery function. We deliver high quality products and yeah, just lots and lots of buzzwords and all the kind of things that maybe make you excited or maybe not. So, yeah, get interested and get in touch. So the three topics we've got this evening are building stable Iraq, Tomica, front entrance from even setting up future flags with react with Tallia and presenting without showing my screen from some first office and house rules. So no one behind and everyone's just volunteering here. Everyone's giving up their evening and put themselves out there and talking to just ask questions. So if you want to hit the Q&A button and you've got any questions for the speaker, then put them in there and we'll address questions at the end of every talk and then do that social media thing, if you like. Yeah. However you want to get in touch, I think there's all these things that you need the button, the ups and the hashtag. Next is a new segment trying out react news. So what's been happening in Iraq? Well, since the last minute. Do it wouldn't be a presentation without a little flying from the right there. So 17 release, which is so exciting and it contains no new features. It's kind of the equivalent of getting a massive big box or wrapped up with a bow, opening it to find a tiny buyer inside. But it does pave the way for future releases and to do some really cool things. And so, yeah, we wait with bated breath for vegetating. Cool. Now onto the first talk, which is building scalable to microfinance with Rubin. So I had no little blurb. I was kind of buried underneath everything. Oh yeah. Here we go. All right. Cool. OK, so Ruben is a developer at American Express. He is part of the one up call team building and maintaining a new framework for services rendered Microsoft Renton's in React. He's very passionate about this topic and hopes you and your teams can benefit from this new front end architecture. So please, everyone, welcome Ruben. Thank you. Thank you, Tim. I hope everyone can hear me OK. OK, so let's get on to it. So, yeah. So my name is Ruben again, myself, a developer at American Express and really, really passionate about this topic. So I am a front and microphone advocate. I like to share these new architectural pardon. And before we get started, I'm going to tell you a story. So let's imagine that is Harpo's five on a Friday afternoon and you have to deploy a fix to your application. And that fix is very important. So you definitely have to do it. And because we follow test driven development, we have about 50000 unique tests. You know, the integration tests and the build might take about several hours or maybe a whole day. So you wait until the build is complete and you're about to push that button. We don't push buttons anymore. We probably rely on the CCD. But let's say they are about to push that button and you get a text from another team member and they say, oh, you know what? Do you remember that comment that we pushed last week to enable Darmody? Well, it hasn't been approved, so you can't really see the production now because the changes are bundled. So at this point, you know what you're thinking and what you're thinking, it just want to cry. You just want to go home, enjoy your weekend. You don't know what to do. You have to abort to build and you probably need to go home. You want to go home and change careers or something. And this might be just a very hypothetical scenario. I know there are some ways to fix these issues, you know, like feature flagging. For example, we're going to look at that today. And also you can restructure teams in a better way. But what if this is something that is happening to you? If it is something that has happened to you and you are part of a large team, you might benefit for a paradigm switch. And this is why I'm going to talk about tonight. So in case you didn't notice, the stock is about my front ends and get so first of all, because it is the custom on everyone before they start at all, they say. So microphone things just very quickly is just a new way to build applications. It's a new architectural paradigm, a new design, a way of creating from the applications. And it's just basically splitting your Front-End application into small, independently deployed in the tested applications. You can say if you are familiar with the micro services architecture, that this is just basically micro services. But for the front end now, what are the benefits? Because you don't just jump into different architecture just for the sake of it. You probably need some benefits from this architecture. So the first benefit that you get with microfinance is you get independent deployments. And this is very important because as the example I was explaining before, nothing worse than just depending on other teams for your deployments because you're having different deployments, you have an inherited reduced risk, so you only deploy to production what you changed. You probably know this is one of the main roles in software development is if it's not broken, not broken, don't trying to fix it. So you get quick fixes to production and also simplify testing because you can focus on the individual functionality of your front end and make sure that they behave well, then have them into and you can also integrate them, integrate them and have a suite that runs just for regression purposes. But you can test your microphone individually. So that's number one. Now, number two, what you get when microphone tense is independent teams. So you could have if you look at your structure of your company right now, for example, if you are part of a large company, you have the the front end team and the back end team and sometimes the back end team. It's got a lot of teams that they make their are micro services and they handle different parts of the application. But on the front end side, we still have a massive what we call the monolith and is just one product. Everyone has to coordinate with everyone, make sure that you have release cycles, that you test properly and that you don't touch something else. So with independent teams and microphone tense and you could separate them and actually. The is full stack from back to front end as a full ownership tire of one team, so one team can actually own the end to end of that feature and release it to production without having to coordinate with all the team. And also that avoids obviously dependency and interference with other teams because they are independent and they don't really care what other teams are doing until they have to do some sort of integration. But at that point, your future is already tested and ready to go to market. And obviously that's another benefit you call faster time to market. You get features quicker because you remove all the dependencies. That's number two. Now, number three in terms of benefits is you have the couple called bases. I don't know if you are like me when you arrive to a new product, a project or you have you just been hired by a new company and they say, OK, this is the front end and it's a massive, massive application. You don't know where to start. You don't know what page renders what. You have to go through a whole code base to find what you're looking for. With microphone tests, you can actually decouple the code bases and every single microphone turn has its own repository. So if you, for example, you want to make changes to the account section of the websites, you know that there is an account repository, for example, that you can go and find the change they have to make. Also reduce the scope because you know that you only have to make changes in the account section. You don't have to make changes somewhere else in the websites. So it focuses as a developer and improve developer experience and avoids the accidental coupling. If it's something that you shouldn't touch it, don't touch it. So you don't have to care about the other sections of the website. You only touch what you need, which is the account section and finally won the last benefit. And this is something that people don't talk about much when people talk about micro contents is reusability. Let's imagine that we have a community of developers that create react applications. At the moment we have components and those components are fine. But what if we have an encapsulated user experiences that you can reuse and then just bring them to your website and you don't have to do anything else. It's just built by someone else and it has all the APIs and everything needed for the application. An example of this could be like a fly. It's kind of micro content that has all the logic to handle the different dates, airlines, etc. and thus built. And it looks nice, it looks great, but also handles all those API API calls that need to happen in order for that tiny piece of UI to work. And it can be used by other applications and it can be used by your own team. So if that team created the account section and they created a nice widget they can get that widget can be reused by another team. Great. And unfortunately, nothing is perfect. And microphone things are not a silver bullet. They are going to fix all your problems. But first of all, if if you're a single developer, if you are working on just one project you want, you have just one team microphone. Things might not be the right approach for you. We are talking about scalability. We are talking about large, medium to large scale applications. So if that's the case, if you have a small application, you're on your own. Maybe that's not ideal, but these works really well with large teams. However, there are some tradeoffs, but trust me, the trade offs are nothing comparable to the benefits they get from microgrants. So, for example, one of the trade offs is the complexity. If you are familiar with micro services and you know that there are more moving parts, more configurations, things they have to do to make sure that all those micro services talk to each other. So there is a little bit of increased complexity. But if you are part of a large organization, that should be fine and also is a different paradigm. So you might need some training or you design your applications in a different way so you can benefit from this paradigm. Right. So I'm going to introduce because this is really meetup is a framework, part of I'm part of the one up core team and we designed this application, this framework to create a scalable microfinance using react. And the main benefits of using one app is there is services rendered by default. So what is one up? One up is a new model or approach to Web application development. And basically, yes. And we decided to do this is because once you start to scale your application. My need that boost of having a framework that is going to help you scale and use microfinance so that one up framework has two parts, and the first part is there is a server that does the server side rendering and is A.J. Najai server that basically handles all the requests is the orchestrator that when a request comes in, you will assemble all the many pieces of a UI, all the modules, as we call them, into the page. And that's what you sent to the client. And the second part is Holloran modules, and we call them hologram modules. So if you look at the established definition of what Calacanis, you realize why we decided to call a hologram is an independent. Basically it's a microphone and this is an independent application that can be tested, deployed independently. But when you combine multiple holograms, you get the whole UI rendered on the page. So if you are a developer trying to use one up, you don't need to do anything on the server side of the application. You just create your hologram modules and one app will render them server side and assemble them on the page. OK, so what are the benefits of one up or the features of one up. So one up will provide modular design. Modular design is provides code splitting by default, so every single module on your page will use code splitting and it will have its own bundle. Joska bundle. So the bundle is a small we have a performance in mind, so we make sure that those bundle sizes are small and you can even split that module even further to make it different chunks of JavaScript on application. And obviously the main feature is server side rendering by default. So by default, all these microphone tents are server side rendered and we take care of or we are really stressed security and make sure that security is important, very important in the design of one up applications because it's important to have the best practices. For example, by default, one up will include the content security policy enabled by default. So you cannot talk to APIs that you are not allowed to talk to. And then the Supersaurus integrity for all those JavaScript bundles I was talking about before, all of this enabled by default. And obviously, if it's a large application, you might need a internationalization enabled. So when I will create all those language backs by default, I just need to translate Europe in some very easy to customize Jason files and one which is output the the bundles with the language box and also independent deployments. So every single Holloran module has his own Cecily's pipeline. So you can deploy to production without restarting the server. So no server restarts. You just deploy that to a CDN and the server will pick up that new JavaScript bundle and you don't need to restart the server. Basically, the server is running somewhere in the background for you and you don't have to touch it. You just deploy your microphone tenso, which is a very big plus. If you don't have to restart the server, you don't have to. You don't interfere with all the work that is happening. Okay, so I know I'm going really, really fast because I want to do a quick demo. We are really close to the demo. OK, let me just go back. I'm just going to share probably the same production architectural the just quick so you can have a visual representation of the demo. So the modules are deployed to a CDN that can be stored anywhere, just any CDN provider. You can even deploy two different sedan's. You know, you can have one mentally file, another one on surge or whatever, and you decide to use and there is a module map which has the list of all your modules. That module map is just basically if you compare this to the package to Jasen of your components of your NPM packages, that has the list of your modules that are deployed to a production and all their versions and locations on the CDN, then what happens is the one observer will check that module map and then load the modules that are meant to be in production, load them into memory. And when the user requests a page and makes a request to that, you are out, the one observer is going to the one observer is going to render them on the page and assemble them together. So that is what happens in production. Now, in development, we provide some tools to make this easier, because as I mentioned before, there is a server involved. And if you have been developing static applications, you'll be like, OK, there is a server. What do I do? So we provide a docker image that provides the server functionality. Again, you don't have to do anything with Docker or you need to know Docker is just running the background for for you so it can serve your modules. And also we provide a local CDN that can serve the modules that you're working on locally. And we are going to have a look at that in the demo in a second. So, again, you don't need to know anything about Docker. As long as Docker is installed, you can run. The server is a very easy way to do that. There is an alternative, but it involves a couple of commands on the actual server to register your modules. So the takeaway is just the easy way. But if you're unable to download Docker, then there is another way to run the server. Great. I think we are ready to have a look at some reac code because I'm pretty sure that everyone, you know, you don't want to just look at some slides on the on the screen. So let's have a look at this. I have a very interesting example here. And if you look on the left, you might be thinking, OK, what is this flat for the structure? To be honest, it doesn't have to be like that. You can store your modules in different file. There's obviously they have their own repository. So at the moment I have free modules here and the root module child and the grandchild, and they can be anywhere on your machine. They don't have to be part of the same root folder as long as you can reference them locally. And also you can have modules that are deployed to production and you don't have to have them on your machine. They went up server will load them from the CDN and serve them on the page. And when you're not developing. So here we have so we have the Holocaust route, which is basically our route module. This is where we set the configuration for application and we configure the routes and configure the other modules that are going to be rendered on the page. So I'm not going to go into detail about basically what you do is in this case, we have a route path and that's just basically empty that will render the route module. And then we have two routes here at least route and added to Rouf and they in at the same time they invoke the two other holograms. And remember these two modules here, they can have their own Geep repository somewhere. They can have their own secedes pipeline. They they don't know, they don't need to know about each other unless they interact. So they are completely independent on the page. So we render render these modules en route. So we render, for example, the detailed route will render my first child module. And if we look at the first child module, we have just a very basic component that that is going to render some Star Wars stuff. I probably have seen the team going on with Star Wars and hologram is going to render the grandchild so the grandchild will render twice, you will render on a route and also will be rendered by and the the first child module. And if you're familiar with Rijad, composition, which makes you react really powerful because you can basically reuse your components, one component can load another component and then reuse it has many times you like. This allows staff composition model to be extended even more by just combining all the business logic into a very composable reusable module. Now, let's see what's the output of this? So I'm in my group module and the only thing I have to do is do npm start to start the server that will use Toca to get a the latest version of my server run in the background and. Like Cotting never goes well, let's see if this should work. And if you go to localhost three thousand, OK, so we have this is the root module. This is the first holloran they created. I put a line, a border so you can see where the module starts and ends. And the root module again, is the entry point of your application. Now, from the module I navigate to this path that lesra out. I have another module just highlighted in red here. This one is the list module and it has some starwars. LB. So you can see that this module renders the second one on this path. Now, if I click on one of these, it will render the third path in the data round. And we have three modules right now, so we have the room module rendering the logo, the detail module, render some basic information about this film. And if you can see the list module is being reused, you can have the list module on its own here. But I'm actually reusing it from the detail module. So you can actually go back to the list underneath. This is a very basic, basic example, but you can look at the structure and you can be like, OK, my application has read separate boundaries where I can just basically they gave this to a separate team and say, OK, Team A, you are very you're in charge of a detailed module and that's the only thing they are in charge of. You only need to make sure that the codes API orender is fine and you can deploy that as many times as you like. And Team B will be in charge of the list module and they don't need to know anything about team say they can just create a separate application here and that can be deployed independently. OK, so this was a very, very quick introduction to microgrants. My last thing I was going to show is obviously this is server side rendered. So just to make sure that people see what's happening, this is react. And as you can see, this is all services rendered, enabled by default. So you can see that this is coming back from the server and the hydration is working cool. So very, very quick interaction. I'm going to probably ask some if people have some questions. And I don't know, Tim, if you want to if you have any questions ready for us. And first off, General, like. Loud clapping and applause Yeah, I mean, this topic is very big, so I unfortunately try my best to compile everything like a really small 15 minute talk. But yeah, this is probably have a follow up at some point. Awesome. OK, so we do have to go. I got a couple of questions popping up. So the first one is and do you still share common components between modules and how do you do it, e.g. a common busson component. Yes, you can at that point, you can use an AMPM dependancy, so if you have your, like, react library with all your common components, you can have an import dependency shared across all the components and to avoid the duplication, because we don't want those bundle sizes again, going bigger by including a lot of dependencies again and again. And one up has a feature called Well, actually from Westpac, where you can do your externals so you can add to Westpac externals, all those dependencies that are shared across all the modules. So they are not included in the bundle size of the modules part of their root module. In this case, that that is the way that we do that at the moment. Awesome. Next question. So there's tons of questions, I'm not sure how many will get through. Cool. We do know from Julian, thanks for the presentation. Went on the detail route. Can you pass props to the last module from the detail module? Yes, you can so what you do is just pass the props from the router and then you just use them to render. So that is something that we for example, there is an example module in the one up repository that we use for demo purposes. So you can have like a catchall route that will render any given module and you just pass the props to customize the way it looks. That's just one way of passing data to a module. So that is completely possible. Yes. Right next up from Lucy, how do you handle state management across modules or microphone types, for example, if each module needs to access the current user data? OK, so first, the state management, obviously, you have you need some communication, but this is just a change of design and paradigm microphone. They should be as independent as possible. So they should call their own APIs, get their own data. They should be isolated as much as possible. That's obviously the case where you need to access data on the page and state on the page where you need access data from another module. In that case, there is a global store, in this case for one Apicella Global Redock store, where you can pass data between components so it creates a global store that the app uses to do that communication. So, for example, that's the way that we know what modules are loaded onto the page, what modules need to be rendered by using that store. Next from Thomas, do you have solutions for sharing state or caching API requests between the microphone? Yes. So basically that's the main issue with microfinance and we're working with APIs is obviously you don't want if microfinance are independent, you don't want to make a duplicated API requests. So if, for example, the was that detail module is already downloaded, the data, you don't want to download the data again from the list module. In that case, we have a couple of libraries. One up doesn't prescribe you a solution for it. We have a couple of libraries that we use for caching is basically the cache are stored in the global redock store. So when a request comes in, if the cache is already present, downloaded by any of the other modules, if you use that cache instead. So we have one library right now that's called Awassa and it's just basically handling that that data fashion and cache mechanism, which is basically you can load data from rest RPK of graphical well and it will hold the cache in the store and then you don't have duplicated calls. Nice. So one from Rusman, great stuff, thanks for that. How would you recommend handling a react upgrade? OK, so this this one is this very different approach, because if you hear about microphone things, you will hear people using different versions of libraries, even for example, there is a use case which is valid. This is, again, just this is very opinionated from from me. And he's saying that we don't want to have different versions or different frameworks acting on the same page. And that's just the way one up prescribed the microphone approach. So we don't have a view and react and angular or different versions on the same page. We just focus on and react. And one version of react, the application itself, the one up framework itself, has compatibility compatibility between the modules. So if one module is not compatible with your question, you can take that module and say, OK, this module is only compatible with the version of the app up to this point. And if you try to load that module on your app has a different version, it will just not load it and you will gratefully tell you when it's trying to load it on. This module is now available. OK, I'm taking two more questions, but there are quite a few more, I think we're going have to invite you to talk at some point, but you can always provide written answers to those questions later, so. Well, tomorrow. So how would you how would this be incorporated within an application by the state management framework such as Redhawks? Uh, how to avoid say the question again, because I'm not sure if I would be inclined to an application white state management framework such as Redhawks. So one app uses Redhawks, I'm not sure if the question is to avoid redux, but basically, you know, people complain about rehook sometimes because they're trying to introduce Redox to their small application. I mean, Redox is better suited for large applications, like, in this case, microphone things. So one app uses redux. That's the basis of the app. And we use readdressing redux in the background for state management. OK, great, and final question from Thomas, can we see the config files and linking to my career instance? OK, so there is a difference. Let me just show you some code. So basically you have. In the room, Ijaw or. In development, I mean, just, uh, this is not the right one. This is the first out in the road module in development. You have the list of modules that you want to load in development. So at the moment, I'm loading the first child and the grandchild and they are loaded locally and it will combine them with any modules that are deployed to my application. Now we production there is, as I mentioned, a file called the the module material, which is the module maps, which is basically adjacent file that has the list of all your modules deployed to production. And that's when you deploy you basically just update this file and then point to the location of the CDN where your module is deployed in production. So there are two things in development. You just added to this array in production. There is a file called a module map, which is just a basic data on file that has the list of all your microphone tests developed and deployed into production. OK. All right, that's, I think, all the questions we have time for, so everyone give it up behind your computers and message, if you like, maybe in the chat and give your appreciate or even for the next one talk. Thanks very much. Like. Thank you very much. And again, let me just show and I'm so next up, we have we have Tahlia giving a talk on setting up future flags with React. And so Taglianetti is an international keynote speaker. He delivers content on all things testing and quality. She's a developer advocate at Split Time, where she works closely with engineering teams, global leadership software more efficiently. She is passionate about future future flagging cannery launches, SYTYCD testing and production and a B testing. She's spoken at countless conferences internationally, ranging from audiences 100 to 4000. So I give it up to you tire to take up that. Q Thank you, Antonia. I'm just going to share my screen here. Can I see so you can see my son? Perfect. All right. So we're going to get started. And I want to start off by setting the stage a little bit. So let's say that I'm a front end developer and I am working on this to do list. And right now, my users only have the ability to add tasks to the list and I want to add the ability to delete. So adding this feature requires some backend work because I need a new API endpoint and I don't know if the backend change is going to be ready in time, but here's what I've done so far. So I have this conditional statement set and by default, the user is not allowed to delete and this is the current state. And then when I test this locally, I flip this boolean to true to test stuff out. And then once the backend is ready and I want my users to be able to see the delete button, then I'll just push this comment with the Boolean equal to true. And what's great about this is that if there's bugs with the backend API or like or if something goes wrong, it's relatively easy for me to just temporarily roll back this change, fix it and then push up a new change. Right. So what I've basically created here is a super basic example of a feature flag and a feature flag is pretty much a piece of code that lets you separate code deployment from feature release. And there's so many different use cases for this. We just saw one example of how we want to use this. Like if different parts of a feature are not ready and you want to wait until the entire feature is ready before you do a feature release. You can also use feature length to test features and production to ensure proper functionality. You can use it to perform a B testing to figure out which version of a feature gives you a higher conversion rate. And then you can use them as a kill switch, which allows you to turn off a feature for everyone in case something goes wrong and you need to hide that feature. You can use it for subscription management to manage permissions for specific user groups, can use them for a canary release or percentage rollout where the feature is only initially made available to like just a small subset of users and the user base. So that, like, if there's any technical issues, they'll be identified and resolved before it's made to the entire user base. And then you can also use this to migrate your model S to micro services in like just a safe and controlled way. So there's a lot more. But I hope you understand like what a feature flag is and its capabilities. And why do we want to care about these, like why our future is so important? Because they allow you to improve your ability to develop, test and deliver new features while minimizing risk. And this is just a very good foundation for continuous delivery. And this is how you can impact a measure of your changes. So let's allow you to directly correlate the impact of your changes by pushing information about the feature effects to the internal analytic system. So your business decisions should be based off of data. And using a smart feature fobbing system will give you that data to have a successful business and to make the right changes for users. So in your future thugging system, this is what it looks like in split here. You can see which you can set who sees which feature without ever committing new code. And this is really great for like product owners and non-technical people because they can control the user experience without having to ask the developers to commit new code. And it also supports multiple projects and environments while you can target users based on the information that you provide. So going back to our example, if I want to roll out this delete functionality, I want to roll it out in a controlled way using feature effects. The basic thing I had previously like that if if else statement, it was fine. But if I use a feature blogging system, I get way more control and I can turn things on and off without touching code, without pushing up new code. I can also target specific users or types of users and then split these possible states of what your user can see are called treatments. And so for this demo app, the treatment controls who can delete tasks. So in our case, when the treatment is on, I'm saying you can delete tasks, you have the treatment. And then when? The treatments of the user will not be able to delete tests, and this is what it would look like in each case. So what I had before this, if then if sorry, if else statement, this is the super hacky way to do it because you're hard coding whether or not the user can delete and you have to keep changing your code. So this is the right way to do it and react where depending on the value of the prop, you're either going to show the delete button or you're not going to show it. So what we're going to what we're going to do today is create a feature flag, install the dependencies, configure your react up instantiate and use the SDK. And then at the end we'll talk about, like, best practices to, like, pull everything together. So the first step is to create a future flag and I'm going to show you how to do it and split, but like a lot of the features, like providers, like it's all pretty much the same UI. So this should be standard across like any future management tool that you use. So after you log in, you'll see a button that says create your split, which is another word for feature five. And then once you click on that, you're going to be prompted to enter some details about the flag. And the first thing you need to do is name your five. And this is exactly the name that will be in your code. And you should be pretty descriptive of what the flag is doing. And I'm going to talk about this a little bit later on when I talk about best practices. But just notice here that the name of my flag that I'm creating is Tolia to do is delete, and that's what I'm going to put inside of my code. And then you also want to select a traffic type. And this is what differentiates the people who can see your feature and the people who don't feature. So this can be by user location device. So if you want to roll something out for like only iOS, then you can put device and then select iOS. If you want to roll something out to like only people who are in Europe, then you can select a location and only target people who are in that location. So this is pretty customizable. And then in my example, I'm saying I want myself and my developers to be able to delete and everyone else gets the default existing behavior of only being able to add tasks. So if you look in the targeting rules, I have me and developers. So if your name is not here, you you then move on to the default, which is. So next, you want to install the dependencies and there's just one that split provides, and it's just basically the tool that is used for future logging. And you want to install this in your folder? Pretty standard. And then you want to instantiate and use the SDK and this is where the fun kind of begins. So the first thing you need to do is import the JavaScript SDK. So at the top of your component, you want to import split treatments and with split factory from split. So split treatment is a react component that performs feature evaluation. And we're going to use this in our render function. And then the Winslett back to a higher order component is used to wrap the to do list component when I export it. So I split up my render function in two and in the first one I return the treatment and configuration from split treatment and then in the names I pass in the name of my feature like that I created from the UI. So that in the second render function, I created a variable named allowed delete that differentiates between treatment on and off. So again, if I'm saying if the treatments are new, allowing the user to delete tests and if the treatments off, then there's no option to delete. And then I have a function called create tasks that gets called in my render function and conditionally renders the delete button if you allow delete variable is set to true. So after the render functions, this is where I entered the configuration that I'm going to use to configure my split instant and that initializes what's left factory, which is the entry point of the library. And what's important here is that each user is going to have their own authentication key and you can find yours sorry, authorization key and you can find yours in the UI. And so in your configuration, the key parameter is telling split who the current user is. So in this case, when you run npm start, you're going to see the delete button because you're targeted in the flag. So remember, previously I targeted myself and now I'm telling my app like login as myself and then I'm going to see the delete buttons, as you can see on the right, because I'm targeted. And then when you set debug to true in the configuration, you can see all the logs from split in the browser console. And you should pay attention to two things here. The first is that you can clearly see that I'm the person who's getting the treatment. And the second is that you can see that the treatment is set on for me. And now watch what happens when you change the key to a user who's not targeted in the split, you can see that the delete button disappear because this user, test user, but daddio, they're not targeted. So remember, only myself and developers are. So these anyone else who tries to access this feature is not going to be able to access it because remember, the back end section is it isn't ready at the back end. APIs are ready and I'm waiting for the back end team. I notice in the console logs I clearly see that treatment is off and now I'm getting the default behavior because I'm logged into someone who's not targeted. So I want to quickly go over best practices now we know what feature phones are, we know how to implement them. I just want to go over best practices. So when we look at the feature thug life cycle, we have four stages creation, implementation, roll out and clean up. And I just want to go through each of these steps and talk about the best practices for each section. So the first step is creation, and the first step of creating a feature is to create a naming convention. And there's a few options you can choose from. And some of the things you can do, ah, include the ticket number. If you use like Jira or Azana or whatever management tool you use, including the name of the service, include the name of the team that the flag belongs to, include the name of the functionality. So like what is this feature doing. And then you should also engage with the different stakeholders on your team to define something that makes sense for all of your teammates. And just be sure that there's clear ownership when you create this flag to reduce friction later on. And something I always like to say is like, if you don't have a concrete naming convention in place, it's like when you have siblings and your mom goes through every sibling before she correctly identifies you. Like my name, Talia and I have a brother named Trevor and a brother named Tyler. And like growing up, if I would get in trouble, my mom would go, Trevor, Tyler, Tolia, like she would go through like all of the siblings before she got to me. And you don't want that to happen to your future if you don't have to go through like one hundred future flags and figure out which one you need, you want to look at one, know what it's doing by its name and that just provides consistency. So consistency is key here. If you start out with one naming convention, make sure to keep that consistency throughout your project, and that's just going to help you avoid confusion later on. And then the next step is implementation. So there's a few things to remember here, your changes to your your efforts should be treated like code deploys. So if you require in your code base to code reviews before someone gets to merge their code to master, and you should also have two reviews for any configuration changes to feature flags. Even though you're not writing code and the feature flagging system, the changes you made can directly impact your users in production. So you just want to be really careful. And so by having the same approval process, you prevent people from making a change to the configuration of a flag that they don't own or that they met to make for a different flag. And this prevents mistakes that could have been solved with by using these approval flows that are integrated within Splett or within your other feature thugging framework. And then you also want to make your logging decisions on the server. And this is a good idea because it does three things. So the first is that because a single page applications are already making a server side call to render the data needed for the UI, you can make a call to the feature service at the same time so that one network fetches all the feature flag evaluation's with the server side data. And then if you have to kill a feature for some reason, like how would your client side feature thugging system find out, what would you pull for updates or like what would you do? So keeping your decisions on a server helps to reduce the changes of cache invalidation. And then lastly, making these decisions on the server side significantly decreases the complexity of the feature blocking system. So it's just a best practice to do it on the server side. And then you don't want to change the scope of their components just to support putrefying decision. So your five decisions should be encapsulated as much as possible while making your final decision as close to the logic as you can, thereby avoiding the need for every part of your code base to be aware of every component. And then when you're testing feature flags, it can be overwhelming when you have a lot of flags and you don't know which combinations to test or you don't know what flags are going to impact other flags. So it's important to ask your product owner, talk to your product owner. Sorry, my dog is speaking out right now. Ask your. Ask your product owner, which combination of flags brings you the most business and what's the most important combination for you to test? And then once you have that list of like the most important flags, the most important combinations, then you can use your automation users and target those users inside of the flag. And that way you can validate those test cases with those test users. OK, the next step is roll out, probably the most important thing here is that users should consistently have the same experience. So increasing exposure to a feature should not affect the current exposed population. So if Johnny sees treatment on and you slowly roll out the feature from five percent to 10 percent, then Johnny should still see the feature on that. That increase should not affect the already exposed population. And then you want to build a feedback loop, so the great thing about future plots is they allow you to make controlled changes to your systems and then you can observe the impact of these changes and make adjustments as necessary. So if you turn on a feature for half your population and your metrics are showing a decrease in activity, then you should kill that feature and adjust as necessary. And then on the flip side, if the metrics show a high conversion rate, then you should keep that change and roll it out to everyone. So it's important to use the data from your feature flagging system to measure if you can move from a smaller percentage to a bigger percentage roll out or vice versa. And then you also want to set up alerts to page you when you get any statistically significant changes. So if your business metrics are being really badly impacted by any change, you should be getting pretty violent alerts through like pager duty or whatever application you use. And then on the flip side, if you get like neutral or positive results, maybe you can just set up like an email alert or something like a little bit less aggressive. And then the last step of your future life cycle is clean up. So you definitely don't want to be stuck with one hundred future flights that serve their purpose. And then we're just forgotten about something super useful you can do. And thinking about removing the flag is assigning an expiration date for each flag. And once that time hits, it's time to go back, delete the old code, delete the flight, because it's already been rolled out to everyone. And then you also want to set up alerts in your future tagging system that will poke you when a flag is still or hasn't had any impressions in a while. It's kind of been sitting there. You want to be alerted about that. And then you can also look at a subtask to your back log to retire the flag at the same time that the flag is created. So when you create the ticket in your backlog to create the flag, make sure you also create a ticket to delete the flag once you eat your definition of time. And then, of course, be sure to remove the old code when you delete the feature flag because you don't want stale code in your code base. And that's it, so you've implemented a feature flag with React and you've learned the best practices and now you're an expert. So in the future, you could use this configuration to deploy all of your changes in a controlled fashion. You could also deploy to production while keeping the flag off by default and you could test in production and ensure functionality in a safe way. And then once you know that it's working in production, you could release it incrementally or to all users at once. And you can do all this without any code changes. So I'm just going to include, like some useful links. So I have a video on features like maintenance that kind of talks about what I talked about today, but a different perspective. And then if you want to go out and try out a feature, Fox can use what I offer a free feature flogging account. And then I also have a repo that has all the code that I went through today. And this is my contact info, my email address and my Twitter. You guys have questions or comments? I can also answer things now, and that's it. Thanks for listening, everybody. Thanks to all of you. All right, so if anyone's got any questions, then, of course, use the Q&A button to ask them. Now, just as a reminder, if you want to see the questions that were left outstanding that Ruben has very diligently answered and with text's responses, then you can go to the answered questions in that section. So kicking off with questions, Battalia. And first off, you go. If you use an external API like Betio for fetching features, how do you make sure the features won't be impacted by ad blockers, network issues, etc.? It tests in production. All of these cases that are that you can't replicate in like a dummy environment and testing production. There you go, the beauty of the feature flags and AP test go next by Christopher how to identify users in the developers list. Do you need to be logged in to put the same browser? OK, so the way this works is it's just like a normal, normally normal. You would have like a list of the developer's accounts or email addresses are like a lot of users do, like company account IDs. So those are like individual users. You could also add groups, but they would just be configured inside of it. So normally it's just like person by person and you can add groups like developers or design or whatever, but they would have their own group within like a split or the configuration. OK, this next from Illiad on feature flags, we use simple Jason files to represent the config fetched at runtime and the flights are available as API response. The Jason configuration is deployed independently from the code. Don't you think it's better and more decoupled approach rather than using an external input? What do you mean by. And I understand the question, it's a better and more decoupled effect other than using the external import. You mean squit? I guess so. No, I'm kind of trying to guess I'm a developer advocate, but I'm going to say no. All right, cool. This is the downside of this remote and react. We can't get into a heated debate. But if you want to chat with tell me more about this and feel free to use the functionality. You can explain a little bit more what you mean. And Thomas asks, Can this feature Flecking product be used to implement AB Testing or MBT? Multivariate testing is also reports of feature enablement, yes and yes, so in the split configuration page, you'll be able to link your feature flags to be tested for multivariate tests. There's there's a lot that you can you can add as many variants as you want. And there are there's a there's a metrics report that's automatically generated with each test. So that's all within split. All right. Peter Mitchell asks, How do you keep flaggers in sync with the back end? It's automatic, yeah, it's automatic split that's up for you. That's done, OK? And finally, Christopher asks to split, manage the abbey splitting or do we need to manage that in our own environment? Just manage the nose. What does that? OK, yes, then and cool. The split is the future. It's automatic, but when there's no connection, then it pulls every 15 minutes. Done. OK, I think that's everything nice, thanks very much. You again. Yeah, thanks so much for featuring. In the meantime, sorry I had to get a pun somewhere. My pun count is very low this meetup, so I'm just trying to claw that back. OK, let me just share my screen in. All right, so a final talk, which you're going to go straight on with, is presenting without sharing my screen by some of us in Disney. And so some company works as a UX engineer at American Express, has built new ways to refer friends on boating experiences and rapid response systems, enjoys teaching the next generation to code through his articles, presentations and hackathon. Of Yeah, give it up for some cool. I hope I'm saying I'm going to share my screen ironically just for the recording. I'm hoping won't need it for too long. So again, hey, I'm Sam. I'm a U.S. engineer at American Express. And just to get it out of the way and do not represent the opinions of any entity whatsoever which I have been hired now or will be affiliated with. So the title of my talk is presenting without sharing my screen or using react to replace PowerPoint and. It's a kind of demo, this this presentation itself is a posse, so if you would like to stop looking at the screen on currently sharing and go to follow the DOT codes, you can play along with this little game and have fun with the experiment. So I'm going to give you a minute to head over that. I see those 22 people already here, but yeah, sure. Let's see if this works. This also is an experiment. I've never tried it with this many people before, but I'm hoping it will hold. Some of the demo does break. We'll have to go back to starting the screen. But it kind of defeats the purpose. If we do so, I'll give it just another 10 seconds. Got 60 odd people in here. OK. Cool. Well, let's get started then. So as you might have guessed from the title of this talk, PowerPoint and me are not friends. In fact, I might go as far as to say I hate it because I'm the kind of person who likes pixel perfection. I like to make things look perfect on the page. I also think the PowerPoint is overly complex to think I'm used to develop a world where we have access to SASO sites and we can make things pixel perfect with numbers as opposed to driving and dropping. And that's my preferred way of doing things. And when you start to think about PowerPoint and the arrows with it, you have to ask yourself when it was born, does anyone have a clue when it was born of the panelists? Any ideas? OK, all right, well, PowerPoint is from nineteen eighty seven, so it's currently thirty three years old and we're still using it and I'm not saying it evidently stood the test of time, but there must be something else out there that's more friendly for us developers to proceed with. So I started searching, I started looking around and I had this question on my mind and one thing I came across was MDX. MDX, for those of you who haven't heard of it before, is Mark down with Janus X put together? And this is an awesome combination. And just to give you an insight, you can you can throw interactive charts, animations or alerts onto your pages intertwined between markdown content. So it's super nice for us devs to use. Just to give you a quick example. This is just an example of the X File. We've got an H1 and markdown from the paragraph on line two, and then after that we just throw in some JSM into the middle and go to the front of the phone modules like we would in our tax code and then online for you can see I'm just using it as you would any other riped input. And this is really cool for blog posts. So I recently did a social distancing infographics post of what the time was counting up, and there was all sorts of matching calculations going on on the page. And this was possible because I could create the component and then input into my markdown. But the heading one and the paragraphs, the top of the page just down. And it's also great for design system documentation because you can have the description about about your components and your component right next to each other, looking nice and pretty and IPY pesticide and gasbags. I'm not going to go into great detail about Gatsby because that's not what this book is about. But I will just give a very quick overview. So Gatsby is a static generator. What that means is that Gatsby can generate pages for you. So you get Gatsby some content, you define a template and then it will programmatically create pages from that template for you. It also has this really cool plug in because it's Eco-System and has this very cool plug in architecture, which is very plug and play so you can abstract, complex stuff away or get other people's plugins to do it for you. And when I was searching for planets to use on my personal stuff, I came across Gastly Plug In and yes. And as you might guess from the name, what this allows us to do is use MDX in our presentation to insert the XML site to create pages. And when I was searching for this by chance, I also came across Gatsby themed MDX deck. And what this does is ton MDX into slide decks for us. This is really, really cool because we can create MDX content on in a single file separated by three reductions and these will become separate slides in our presentation. And this was the PowerPoint alternative I was looking for. I thought this was awesome and I started using this in my presentations. Slides can be sort of stats that the because there are my static sites, I can post the slides as well. So I don't have to worry about getting to a venue and not knowing where my slides are because they're on my site and we can customize the hell out of it because we can use react code to do it. So here's some of the fun things that I thought you could do. And I'm sure you guys have many other ideas. But here's some of the fun things I came up with that you can do in react components in slides. So the first one is using lots of animations so we can have confetti on the screen. And you, as an end user, if you want more confetti, can hit the more button. And it doesn't really affect my presentation. But you get more confetti, which I think is great, kind of adding a little bit more interaction and slides. We can also have interactive codebooks. So if you're teaching HTML or react to in a lecture, you can potentially have interactive elements in your slides where people can play around and have a little go and try it for themselves as they go along. And I think an interactive slide deck might be a more memorable one, the more interaction you can have with your uses, the better. So I was that thinking just done right. End of the road. Oh, good. Well, then coronavirus and social distancing happen. It happened. And suddenly the whole world changed. And I started to question and thought maybe the job isn't done. And so the whole world went online. And just like this meetup, we're all using video conferencing software instead of meeting in person. And when we look at like the average zoom data usage per hour streaming the video in HD quality is 2.5 gigs an hour. SD is no point, six point seven. Sorry, but if it was just audio, it's 70 megs. Right. And I know that Reagan was having trouble with his 3G network at the start of this, trying to stream that ten point five gigs. I'm in a similar situation. Most of the time I don't have fiber. There are other users on my network. I have an unreliable ISP and on top of that, nine times out of ten, I'm working on the VPN for work. And all of this kind of slows down my network and my bandwidth gets bottlenecked. And what that means is that when I'm presenting my slides for those that you want to hit the reality button, when it is kind of what it is like for most people, I think viewing my presentations and that's less than ideal. I prefer, you know, a less dial up kind of feel. So the designer in me thinks this is less than ideal. I spent considerable time putting presentations together and I think they deserve a proper delivery. So I suddenly had this brainwave. I was that thinking, you know, I'm giving my presentations with my slide decks that I hosted online. Why don't I just send people to those presentations and let them follow along as I presented? And whatever I think of trying to create this kind of real time behavior, I think about sockets. And for those of you who don't know what a socket is, a socket is a bidirectional communication channel between a client and a server, as opposed to what you might be trying to continually pull us out to see if there's been a change with sockets. The relationship is both the way so your server can be notified when there's a change, which is super, super cool. And just to give you a little demo of what that's like at the top, I just a little aftertaste that just emits a message to the server and on the server on line seven, you can see we're grabbing that message and we're just slugging it out. But we could also send the message back at that point as well. But what if you want to store this data, right? It's so good having a message come through from the server, but one thing that came up early yesterday is that we would like to store information, whether it's in one up or somewhere else. And one of the answers that came out of that was read and you can combine this with redox team and there is a really cool piece of middleware could really suck it. And online fight. You can see I'm creating an instance of I'm passing it in the socket and then I passing a little string that says server. And basically what that does is any actions that I dispatch that begin with server slash will be service will be intercepted by this middleware and sent off to my server instead of going through the register in my store. If you want to, there's a link on the bottom of this page to get a look at that. And then on the server side, you can see on line 10, I can just grab that action. I can control log it or to limit it back or do anything I need to with that information. So with this, we can actually control the slight delivery, which is hopefully, hopefully keeping up. Let's I don't I don't know how it's going to work with as many sockets, but we'll give it a go, say, controlling slide leveret. So what I've done is on the deck, which runs on all of your screens right now, there is on line seven. You can see this little if on the if is if the index of the page you own doesn't match the slide presentation, which is the one that I'm on, then it will then it will say sorry, it's the other way round. So if your index is the index of my page right now doesn't match the one on the server, I'm changing the presentation position on the server by dispatching an action on line eight. And you can see on that service of the index, which pushes the new index up to the server. And then you then the server sees this and updates the index accordingly. And then it uses Timit to tell everybody else that the index is now this one and not the old one. And then you to the end user, if you're a part of my presentation decks, which is what line six and seven are about, and your slide doesn't match the slide that I'm on, then it will jump each of the presentations and then I'm clicking next on my presentation that it's sending it up to the server. The server is sending it back to you guys and then your client is going on the right slide. I'm going to change it. But you might have noticed in all of that that that would mean that anybody could omit a change and index and suddenly that would cause chaos because everybody would be next on the slides, would go a thousand miles an hour or all sorts of weird orders could happen and add a little environment variable online to the you can see that that basically says whether I basically verified that I am the person who should be presenting. So I just have a little personal server. And at that point I identified to the server that I am the presenter. And then on line 17, when that index is updated, I just check whether the ID that is suggesting the update and index is the one that matches the one that I'm pulling from. So this is this is kind of just like a little diagram of how it works, so I send my changes up to the server and then you will get notified about the change, whether on your mobile device or the iPad or your laptop should all work mostly. But what if I'm going too fast for all in the same room? It's really easy to put your hand up and say, how long can you go back a slide? Just quickly, I had a question, but that doesn't really work on the remotes and there's not a two way conversation going on. So what I decided to do was add an on which you can actually find in the corner of your screen. The padlock. If you click that, it will give you control of the slides again so you can go back or forward and review at your own pace. And then you can look at again to come back to where I am. And that's actually the easiest path to implement in all of this. All I did was add enough of building to a state that was full, which you toggle on or off with that look, and it will only trigger the jump of the slides if that is true. So if you compare this to the same solution, sharing the screen is 2.5 gigs that I want to share my screen per hour with Zaim, my solution is the cost of audio, plus however big my site is, and that's it. So as you can see, this is really good for bandwidth in situations where you don't have great imit. So for me, this is perfect and the stress on my never goes down. Everybody downloads less and the slide should be crystal clear for everybody because they're rendering on your machine. And sockets allow for even more crazy components, and so and these ones are the ones that are going to break if anything is going to break in, this this will be the best. So I know that we have a Q&A in the in the day, but you can actually do QAD in the in the presentation deck and I won't answer these questions, but if you want to throw some fake ones in that hashtag, keep them clean. But if you want to throw a question than that. Yeah. You can see if you come back and look at my screen showing, I can actually see the questions that are coming in. So I could then answer them if I wanted to. Cool. Awesome rights advocate also to polls. So if you are working from home, you could potentially vote. And you should see while 100 percent of you are all voting, all saying yes, can someone say no just to even it out a little bit? Yeah, there we go. All right, cool, so you can see, like, we can have interactive polls in here, so you've got like you might have heard of. That's what my lecturer used when I was at university. But he would have to navigate away from his slides to set that up so that we could then do the polling to come back to the slides. But with the solution, we don't have to do that. So we can also even have stats. I'm a big fan of stats pages and I haven't done this one justice. But you could start to have stats in your slide deck about your slide deck, which I feel like is super meta. But yeah. So there's also some crazy things you can do with this. I hope it inspires you a little bit. I then went kind of stupid with this. So I went to a conference called Half Stuck in May that was online and I had Charlie Jerrard talk. She's quite big on Twitter. She does a lot of crazy stuff with like scrolling with her eyes and stuff with like neural integration with JavaScript. Don't have some crazy stuff. But she did a talk on Postnet. And what it does is it uses a webcam to look at your skeleton and try and work out where it is so you can see all the dots in this gif points that it's worked out where you put your limbs on your elbows, your wrists, your nose is stuff. And this kind of sparks my interest because I suddenly thought when we're presenting quite often we use our hands. I've been doing it a lot during this presentation. I've been doing this and we could use that information to do something cool. So what I thought we could do is if I just had left or just the right, I could increment the slides backwards and forwards. So in order to do this, that's actually really easy to implement in JavaScript in react to there's this code is not mine. I've stolen it. I link to it in the next couple of slides. But basically what we need to do is just pass the canvas. That's what can on it. And then on line eight, you can see I'm just calling the Postnet model and it's estimating a single moment and then it just pushing that to the list of poses that it's got. And basically what that looks like is something like this. So first it gives it a score and that score is how confident that is about the the positions that's given you. And then it gives you a whole lot of key points and it gives you a lot more than the left on the right wrist. But those are the two that I care about. And basically that gives you an X and Y position of where they are. And so what I decided to do was work out if they were both on on the twenty five I'm twenty five percent of the screen or the seventy five percent the screen. And that way I would know that that's the cutoff point as to whether I'm gesturing right or just left. And so both the left and the right wrist have to be over that line on both sides in order to trigger the slide jump. And you can see that the on line eleven, I say set last punch. Basically, I didn't want to I wanted to throttle this connection a little bit because otherwise if I did this, suddenly my Silajdzic machine done because it was like getting every frame. So basically that just said every half second, if I'm doing this, then jump forward or backward. So that's kind of how I'm triggering the slide. I'm not doing it in this talk. But there is a little gift demo here and there is a longer video. If you want to see it in action, it really works. I promise you I'm cool. And if you want to try it yourself, you can see the kite part for the powers that stuff that. And there are some further extensions I want to work on. So Eskow isn't great on the presentations. I'd love to be able to find some slides through Google coding through the app. That's the only bit that's holding me to Zable WebEx or whatever it is. If I could get some way to project my voice across the slides, then there's actually no reason for me to tune in anymore. And then the final thing that I thought would be really cool that I haven't looked at in too much detail is sending sound to the clients. And this is more of an idea, I think, for when you have an audience in real life. But you could potentially use that psychic connection that you've set up and send them all different notes and make them harmonize as an audience using their phones or similar applause, applause, applause soundtrack. And then it would sound like the audience really likes you, even if you're having a really terrible presentation. And yeah, that's that's kind of it. So that's all you can find me on the interweb. There's some deviling some resources and some credits down the bottom. If you want to find out more about the stuff, if you have questions that I don't answer, you can reach me on Twitter. Yeah. Thanks for listening. But like the people they know. I mean, I didn't I didn't hear anything bad. Is there any way to applaud through the through these slides? No, someone mentioned that I should do. I think just like an Instagram story thing where people like having Instagram live on that little hot at the corner of the screen. Yeah. Which I quite like the idea of doing. You could also just hardcoded that bit. Just set to a thousand now. OK, check up. Get to the those of awesome. All right. So I'm a live in the chat for about. So a few questions from Martin. Is this presentation library available and. Is there any licensing around it? Basically, can we use it ourselves easily, especially internally within enterprise companies? And so the answer is a yes or no. So I haven't actually finished the library yet, but it will be available soon. But you see, the problem is it's this Kaspi plug in ecosystem that I've said is really great is actually hindering me a lot because it's all plug ins that are good for Gatsby. But this also needs a server. So finding the right thing, the right place to put it in, the right thing to call it is a little bit of a nightmare at the moment. And but it's getting there. It is nearly done. So there is a small APRC in the meantime, if you want to try this out, my site is open source and has this on it. That's what you're looking at. And there's a site that I can scan, went to the server as well. I think I actually have on my site an article about this in more detail and you can see the examples in that site. If you want to grab it, you can grab it off my site. Right now, if you wait a little bit and you follow me on Twitter, I promise I'll tweet about it in the near future when it is its own library. But I don't think it will just be as easy as an NPM install. They'll probably be more to it than that in terms of Septime. Well, if I mean, if you didn't have any incentive to get to version one, I think you've got like 90 people right here who are going to try it out even as beta test is probably a really good question from Alexei. What about using Web RTC and peer to peer? I haven't thought about it at all for me right now. It was about kind of just making this work on a large scale. But I do like the idea of having just peer to peer so I could give a slide deck to one person without everybody in the world who is on my side knowing that it's happening. But I haven't given it too much, though, right now. But I do like the idea of maybe an extension to the library when I finally get it out there. Nice. Gillian, shut up and take my money, says, OK, so all right, and any further questions, give people just a few seconds to hammer out and this will mean you won't need a to see what you get. Yeah. Cool. Considering. OK. All right. I think that is it. So again, like applause everyone, please show your love and I'm going to return back to my stupid PowerPoint slide show. All right, here we go. And that is actually everything for this month's session. So thanks again to all our panelists, to Ruben d'Italia and to Sam for volunteering that I'm coming and giving such wonderful presentation. So thanks again for that. Really appreciate it. If you want to talk at next, meet up, then get in touch. Look out for news on when our next meetup is. And we've not been quite monthly recently because of things in the world, but we will aim to get back to you as soon as possible and maybe in the real world at some point next year, as soon as we safely can anyway. But yeah, like I'm engaged. Stay engaged, direct and season zero. Thank you, everyone.