 Excellent. All right. Thanks everyone for coming to the redhead.com architectural case study. I actually remember the title. This is great. It's a good start. Yeah. Hopefully we'll have some stragglers come in because we have some awesome stuff to share with you today. I came on to Red Hat Project, work at phase two. I came on to the Red Hat Project a year and a half ago or so now. And we had a chance to build a pretty awesome website and when we launched it, we're like, hey, we can make this more awesome. And so our team, Ryan, Sean and I and a few others, kind of said about how can we make this even better? How can we improve processes? How can we improve the way we're building things? And from that, we created this new architecture, which we want to talk to you about today. So Ryan's going to lead it off and tell us kind of about the challenges we faced and what we did to overcome some of those challenges and then we'll get into some of the more technical nuts and bolts after that. Okay. So like Micah said, I'm Ryan Wilson with Red Hat and I'm the UX team lead for redhead.com. In August 2014, we successfully launched a redesign of our website. But as we entered our next release of new feature developments and enhancements, we knew we had room for improvements. So we set out to identify our pain points and figured out what adjustments we could make to our development and agile practices. At the height of development, we had four large groups of people all creating one website. We had a UX team of 10 designers and developers, a dev team of 10 back-end developers and a QA team of five developers and four business analysts. Matter of fact, we were so big that we actually split ourselves up into two feature development teams. And we all faced challenges. UX, we had lots of manual processes for our repetitive tasks. We lacked reusability in our design patterns. And that was because our implementation was too tightly coupled to their context, which just led to inconsistent designs. And the dev team, they were always waiting on UX for markup, CSS, and JavaScript. And that was because we included both front and back-end tasks in one user story. So we were always the bottleneck. And our QA team could only test after our devs implemented the feature, which meant QA feedback came at the 11th hour. And they didn't have good visual targets to test against. They could only reference outdated Photoshop documents, wireframes, or written requirements. And our BAs had a similar situation to QA. They, too, were only able to review the designs after the implementation. And they could also only reference outdated artifacts when they were talking to the product owner. So our solution was a style guide ribbon development to create a design system. And this approach gives a separation between the front-end and back-end concerns. And so now we have a place where we can actually define the pieces of the component. We can show a visual example and give a little code snippet. So now we have a platform where UX has a build system. We have a separate workflow and a place to create the pattern library. And with thoughtful planning, UX is actually able to work a sprint ahead. And this allows us to build out the complex features before devs even need to begin their work. And this gives us the time to work out all the nuances of our design, find any edge cases, find any of the holes in our UI. So a separate UX dev environment also lets us isolate fixes and make any UI updates without relying on the back-end. And now we can provide the dev team with detailed implementation instructions. We're able to represent all variations of a pattern. And this just leads to faster UX handoff to a back-end developer for their implementation needs. But the best part is that my team is no longer the bottleneck. And QA now has a visual target to test against. The style guide is the basis for UX testing. They can actually perform cross-browser testing sooner, which lets us catch any issues before it gets implemented. And this also just exposes the QA team to the pattern sooner, which gives them a better understanding of how the pattern should look and how it should behave once it's been implemented. So all of this just makes unit testing easier. And our BEAs can verify the visual requirements before the implementation is completed. They can now reference full-page in-browser prototypes during product owner conversations. And so now we're getting comments like this in our sprint retros. Our BEAs are telling us that the style guide is actually helpful in their conversations. And we recently hired a new developer. And he said it was pretty easy for him to get up and running on implementing the UI. So the effect of this solution has improved all stages of our development. It's led to better collaboration across our team. And it's just a great way to keep everyone informed of our UI. So now I'm going to give it back to Micah. And he's going to talk more about the technical approach we took. Thank you, Ryan. Does everyone awake? We need to stretch a little bit of this. Thursday, man. It's been a long week. So I have a bunch of stuff I want to get through. I hope I don't go too fast. If there's something you're excited about, you want to talk about more, catch me back at the Phase 2 booth. I'll be over there around lunchtime. So what we needed to do is we already had designs, which was kind of nice. We already had pretty much a site that was built. So we knew what our target was visually. Just the way we built it first wasn't really the most optimal way to be able to componentize and share these pieces out. We started with bootstraps. Right there, you've got all the CSS and JavaScript. And then we had layers of CSS on top of that, and then some more CSS on top of that, and a little bit more on top of that. So we had all these different banned content types that had a bunch of CSS applied to them. And then we'd go to each one of them and apply more CSS to them, and specifically target each of these banned types to style them out. So what it comes to is we were asked, hey, can we share these things with our other sites throughout Red Hat? And we're like, well, sure, but you'd have to take the markup and all of our JavaScript and all of our CSS to do that, which is a very large debt to start at. So we were trying to figure out how could we break this down into something that's more reusable. And as we took a look at this content, we realized, well, there's actually, there's a lot of patterns here that we could really break things down into. The first pattern is that of layouts. You see, and so helps to be able to see what I'm doing. All right. You see we have really standard layouts right here, like a basic 9.3 layout, some 6.6 and like 50% layouts. We have like a three up column over there. We even have a five up kind of gallery setup. And we have ideas of like cards, like black cards and light cards. So all these layout concepts that permeated throughout all of our design language. So what we want to do is first we capture those layouts into something that's extremely reusable. And it's not something we have to implement on every single band. And then past that, we also, the content that goes inside this layout, we saw a lot of patterns. So we saw that we had this header area. There was always one, two, sometimes three chunks of information. Always styled the same way, always in the same place, something that we could reproduce as a component, rather than having to style individually every single time we built a band. And then we had things like buttons, which were everywhere, that we could really just introduce once and continue to reuse. We had basic links and list items and all these other component items that were constantly used throughout the design, yet we actually had to end up styling them individually for each component. And even the way that we put in media, say like our image thumbnails in our videos, was pretty consistent. Yet we still had to design them and style them every time we built a new component or every time we built a new band. So what we want to do is we want to break those up and turn that into something that was more modular, something that was more reusable. And what we needed to do with that was we needed to create some kind of rules around the way we were building things. You might have seen this slide before, and I haven't talked about this yesterday if you saw my other talk, was this whole road runner rules. Chuck Jones put together this list of nine rules about how the road runner cartoon universe was supposed to act, such as like the road runner can only say beep, beep. And there's no dialogue in the entire cartoon, except for, of course, beep, beep. So we need to have these rules for our design system as well. And our rules came down to kind of simply that we have layouts that never affect the components inside of them, except for giving them a container to live in. And we have components that never do the layout's job. They never care about like how big they are or their margins or their padding around them or backgrounds or anything like that. And then the elements inside of them that have a single class with a single source of styling. So there's one and one relationship. There's one piece of styling that goes to one component and nowhere else. No styles coming from anywhere else, and those styles aren't being applied anywhere else either. So it's one, one relationship made our, or the system possible to be able to be tested and to be able to grow into scale. So a couple of these things I want to go through real quick of some of these tools that made this successful is the idea of a single selector approach, kind of the anti-O of CSS. Instead of applying a bunch of CSS classes to a component, we just have a single class on the component. So here we have the featured topic band. And you see that the class for that is just simply RH standard band title. It's the only class that's ever going to be applied to that, and the only place that's ever going to get styles is right from that one class. There's not going to be this base of styles and then some modifying styles and some more styles and some more styles put on top of that. There's one single source of truth for this. The other thing we do is we have the idea of opt-in modifiers, because not everything looks the same every time. Like you saw we had cards, some of them were white and some of them were black. So instead of building two different cards, we've got a single card that can take modifier. So and as well as not just light and black, but there's also other things to do with cards. So we have a card here that currently has a justify center on it, down at the bottom. We can change that center justification to actually justify. So it takes the content instead of center inside the card, we'll justify it across the card. We can do top, we can do bottom, we can have really anything we want in there. But the point is these are opt-in modifiers. This is a modifier that affects a card only because the card says this is what the modifier does. Take off that class or try and use that modifier on something else. It has zero effect unless it opts into that. And that allows us to know exactly every permutation possible for a card. There's no surprises when you drop this one attribute on there because it breaks something. We know everything can actually affect that. The other thing we do is we have opt-in contexts. In this case you see we have a card with an icon at the top and the icon is white. You're like okay well what happens when it turns white? What happens to the icon? Hey the icon turns black. And you're like hey how is that happening because I thought your layouts weren't supposed to affect the stuff inside of them. And what we do is we have this concept of a context and you can see the theme changes from light to dark in the card. So everything inside of the card can opt into this context. So we've got our data RH theme dark and light and now our link tile icon can basically subscribe to that. It's kind of a pub sub kind of thing. Where it says hey I'm dark and the tile icon says hey if you're in a dark context change to white. If you're in a light context change to dark. And these opt-in contexts also allow us to know that for our component these are all the variations possible. These are all the context that we subscribe to. So we know every variation for that component we can test it. We do visual aggression testing on it and we know that there's no other way that this can be displayed inside of our system. The next thing we want to do is we want to take this grid. We want to make this grid available to anything we build. So we don't want this. Good old bootstrap. Let's throw everything in a container in another container in another container. Classes on everything and put everything onto all of the pieces inside of our grid. We want something more flexible than that. So this is what we came up with. You can see we've got this one content container that has a data attribute for the layout. And inside of that we just drop our components in. We can put anything we want in there. And the point is those components shouldn't have to know what their layout is. It's the parents job to say, hey, you are a gallery five. So here's our gallery five layout. You can see at the bottom there's the gallery five. Now we can easily change it from gallery five to gallery six and the content changes. We don't change the content inside of it at all. We don't have to go in and change class names. We don't have to worry about what row something is in. We can just change it from gallery five to six to four to three. And all the content inside of it because it doesn't care of its size. It's 100% width unless you tell it otherwise. So it's just going to fill up whatever space you give it to go into. And all of our components work that way. So you can drop any component in this. You can have any combination of components that you want. And that parent element is going to be able to tell it what kind of layout to use. Whether that's a six six or a nine twelve or anything. We can even do nested layout. So it gets a little more complicated but is completely doable within the system. The next thing we can do is we can layer on some flex box on top of that. The joy of flex box is that we don't have to 100% rely on flex box layout. We can use it to enhance what we're already doing. Fortunately we only have to really support back to IE nine with what we're doing. But we don't want to completely break an IE nine that doesn't support flex box. So this is a pretty common design pattern you're going to see. You've got three different three different boxes. And of course you can't see the contrast. Yeah. There's a white box around that stupid gray backgrounds. And of course the designers are going to come in and say hey can you make those boxes all the same height please. And then once you do that they're going to say and the boxes are the same height but you can't really see it. The next thing they're going to say is hey those buttons. Can you move those all down to the bottom so they line up. And yes we can do that. And we can do that all without any JavaScript. We can do that all without any absolute positioning crazy hacks. We can do all of that with flex box. And the nice thing is if you're on IE nine you get that. It looks fine. It works. You can still click on the button. It's not a broken experience. It's not visually the same. But that's what you get for IE using IE nine. And anything past that gets the nice beautiful flex box layout. So we're able to use these layouts that work perfectly in all of our browsers and on the browsers that can progressively enhance. They work a little bit better. So putting all this together in a modular design patterns. We start with this idea of a band. The band has got a header, content and a footer. And you can see right now there's already this kind of vertical rhythm between everything. So we got this gutter that's common between everything. So into that we can throw our standard header. At the bottom we can throw a call to action or something like that. And then we take our content section and we can break that up into some kind of layout. Doesn't matter what layout we apply to it. It can take any of them. This is a three up. We can do a four up. We can do a nine three. We can do a six six. It can take any of those layouts. So you can just compose those pieces together. So inside that layout I decide to use cards. So that we have a white card with the light theme. And then even inside the card, the card is a layout structure. So it can take pieces inside of it. It's got a content region. It's got a footer region. And you see that same 30 pixels going around everything besides in between. So you have that consistent gutter already started without really doing any work. Inside of the card, then you can drop more components. So a couple components up top, component down the bottom, and you still have that vertical rhythm between all of your components without doing anything. And this is a consistent style that goes across the entire website that's controlled all by one variable. You can go into SAS, change it from 30 to 25 and your entire system will shrink or expand depending on that number. We don't have to do any work because it's all consistent. So inside of that we drop our content. We drop an image component up at the top, a standard text component into the middle, and then maybe a CTA button, secondary called action down at the bottom. And you're able to compose all of these pieces or all of these bands out of all the pieces you've already built. And that is the power of it. So our rapid prototyping has changed from this, where we take our requirements, we turn that into wireframes, and then development goes off and tries to do something. Design tries to go off and do something. And then you come back as the themeer and go how in the world do I make these things match? You have to go back to the developer and ask them to change markup, go back to the designer and say, hey, this isn't working with the markup I've got, this just isn't going to fly. And we change that to this. Take our requirements, build a prototype, that prototype now gets developed. That prototype phase, we get sign off, we get cross browser testing, we know we have a good quality end product. So instead of doing this, spending all this time on a wireframe, we can take our components, our component system inside of our style guide and build out an entire page worth of content. With all the pieces that we already have extremely easily, just with this big data array that's going to describe how this thing is built. That can be tested, QA'd, signed off, and now when the developer goes to build it, they know exactly the target they're shooting for. QA knows exactly what to test this against, and you have a system that's extremely efficient and allows you to build things at a rapid pace. We're going to turn this over to Sean, he's going to talk about how we actually get this into Drupal. I'd like to start off and say that was the quickest speech I've ever hit. I heard Micah give. We expected that one to go a little bit longer. Sean Owinski, dev lead for the redhat.com site. So as a Drupal developer, I'm kind of like, OK, great, all the flash up on top. What does that mean to me as a developer? How do I get that back down into Drupal? How does it work for me? So what we originally did, and I say originally because there are more slides on what we are moving to, we started off with this internal contrived module, and I put contrived in quotes because it's not on Drupal.org. It's something that's shared only within redhat itself. What that module does is it actually integrates with the library's module, loads the web asset files on every single page, make sure that the actual library is there and can load correctly for systems requirements. Don't know if many other people use those system requirements. We have alerts on those. So if something goes wrong, we get paged. It's always nice to know if something messes up in those type areas. To pull in WebUX itself, it's actually a Bower library. So from our Drupal side, we just pull that in using Bower, and we can specify any version that we want. We kind of work on, they work one version ahead, as they mentioned, and we'll pull in the previous version. Or during the dev time, we'll pull in their current dev version. And it's super simple just to keep switching things around. And that's just, we use that as just like a normal external library that we can use anything else in. And it just goes into sites all libraries. Then each component actually gets its own definitions in there. So Mike mentioned a couple of them. There's ones like Call to Actions, Boxes, or sorry, Cards, the Bands themselves. Each one of those gets into Drupal by, again, defined as a theme. And if you know how the theme works, you actually get to define the theme name, define all the variables that get sent to it, and with template file that you want to use. And then in that template file, we document all those variables to try to help everyone out who's actually going to implement those. So for the definitions of those actual components and the fields, we were like, hey, that's not really going to work if we always just stuff that into themes. So we actually pulled those out a little bit and made those a little bit more generic. And it actually uses the Drupal Forms API to define each one of those components and its fields so we can use those in other places. And one of those other places is Views. So we created a new display for Views. We can say, hey, I want this WebUX View. Automatically adds the certain fields that you need to enter in with its valid values. Speaking of the themes, do you want the light theme? Do you want the dark theme? All those type things. So it integrated very well for what we had at the time. Now, some of you are probably thinking, yeah, that's great. But I can poke holes in that already. And we did, too. So first problem, duplication. Every single one of these WebUX components, we had to say, oh, OK, that's a definition over here. I need to copy that over here in the little Drupal land and create that template file as well as define the theme and all the little variables that go along with it and all the logic that goes in the template file. Just a lot of duplication going on there. The reason why that's bad is these guys are so awesome and they're moving at such a fast pace. What is a Drupal dev team due to keep up with them? Because once we get their next version, we're going to be like, oh, man, now we've got to go change all these things again. So productivity just kind of went out the door on that one. So what are we going to do next? And how do we plan on solving that? I will say this is all proof concept stuff that we're actually still talking about. One of our Klingon co-workers came up with the term WebUX, the next generation, kind of stuck. And we're going to keep going with that one. What we're going to try to move to is WebUX library itself. Actually, the definitions for each one of those components is actually going to be an adjacent schema. And that actually will say, this is a component name. These are fields that it has. These are the fields that are valid for it. It needs one or more of these certain fields. These other ones are required. So it's a very structured, this is exactly what you need to do this component. And currently, they're using SWIG templates over on their side for this WebUX library, which is very similar to SWIG. And we're going to be moving over to completely using TWIG. So then we're going to say, hey, I'm the Drupal in. Drupal's moving to TWIG. That's awesome. We're just going to start sucking that stuff in, so we don't even have to write template files anymore. So no definitions from our side and no templates from our side, meaning the Drupal side. And it's just going to be great for us, because then all we have to do is suck in this library and, hey, we're good to go. So now some of the benefits of why this is actually good for us. Like Ryan mentioned earlier, the UX is already defined. We did start off with UX and Dev in the unit testing and all that. Everything was in one story. Everybody's waiting for each other, and we weren't moving very fast. Now the UX is all defined. And not only is it defined, it's already been implemented. It's already been QAID, cross-browser testing, mobile testing. So none of that stuff needs to be done anymore. So developers can be moving faster on that portion too. The Drupal module, that one's already done with the old way that we did it. We're going to have to make some tweaks to suck in like the JSON schema version of things and then actually render using Twig. So there's going to be a few tweaks there, but once that's done, that's done once. And we never have to do that portion again. And what I talked about just a little bit ago, WebUX updates, when we want to update, when they come out with a new version, we don't have to go back into all the Drupal code and say, hey, do all these templates match up? Do all these theme definitions match up? All we have to do is say, hey, upgrade. And this new library, it's going to suck it in and just work. We hope. Oh, I had the other side. Sorry, I thought we flew through that way very quickly. So what does that lead to for our development teams? Much faster feature development. Originally, we had our developers working with the UX team and trying to flush out what these designs are going to be, what this markup needs to be, what JS needs to be in there, all those glass type things. Now it's all defined. Don't have to do that anymore. And developers can focus only on the things that they need to focus on. And that's the business requirements and the business features. So in my opinion, that leads to increased code quality, at least from what I've seen from where we've been going in this little adventure. So our developers are like, oh, I know their stuff is awesome and QA'd and done all that stuff. All I need to do is use it, and I'm good to go. They don't even have to think about that stuff anymore. They just go in there and do the hardcore Drupal-y stuff, and we're good to go. And that was actually very quick. I know we went very quick, and that was because we only had a half hour. Wow, well, we do have four minutes. All right. So we put our contact information up here if anybody has any questions or more in-depth. We were originally hoping for a full hour to actually dive in and go into more experiences that we had in more detail, but it was cut short. And the, what do they call it? The evaluation for this one, if you guys could do that at the end, too. So now that all those formalities are out of the way and we actually have a couple minutes, you can actually take some questions. It's done through the actual variables that are in the theme definition. So we define everything that you need in that theme and actually have some defaults in there. So I think, what's the default theme? It's like light or something like that. It's the developer chooses. Yeah. And the same with the views integration. Since the fields we kind of pull off and defined on the side, it says, OK, I want this theme field over here that they can actually define on views. And it's just like a little drop down that they can pick from that. And it just gets saved directly. When you do a views export, it gets saved directly with that. Or if they're creating a node, they're just pulling data from the node fields to create the UI that the designers want. And we tell them that this should be a light theme. So when they pass that value in, they can just say, theme equals light. And it gets passed into the system. And the point is they don't have to change from one template to another to be able to use these different variations of the card. We don't have to write any more code when they're like, hey, can we do this one thing but with light instead of dark? It's like, sure. It's already in the system. They can make those changes at any time. And the new with the adjacent scheme of portion of it, that'll actually, when Drupal itself leads that definition file, it'll provide that to different various subsystems of Drupal. It'll still provide it to the theme layer. But then it can get sucked into views or panels or paragraphs or anything else that you want to use. And I have all those in my head right now because that's why we're deciding where to go with those. Any other questions? Awesome. Well, thanks for coming out. And I think, are you up next? You moved. No. Is it Pantheon person here? There's someone going next after us. I think they're going next after us. Maybe not. We rushed through it like, hopefully we won't rush through this and the other person doesn't show up. All right. There we go. I see Pantheon people. We're good. And that is why we were talking so fast and trying to get through that stuff because we're like, no, there's people right behind us. So thanks for coming. Thank you. I'm Drew Gordon. I'm Ron Daly. Together we are the folks who were behind Node Squirrel, which has now been acquired by Pantheon, thus the yellow shirts, very exciting for us personally. And one of the good things that brings to all of us is the ability to have free file backups for every single Drupal site on the planet. Don't need to be a Pantheon customer in order to take advantage of it. So we're going to run that through and show you how to sign up yourself, see what that looks like. So backups. We all know we need backups. Everybody knows that straightforward, but it's one of those things that we don't always do. And so part of that is apathy, frankly, but it's also kind of a hassle to set up. And that's basically what Back of Immigrate was created to do is just solve this problem so it's super simple to take care of backing up your Drupal site. So Back of Immigrate is a Drupal module written and maintained by Ronan and has been out there since 2007, which is quite some time. It's used on over 300,000 websites. So large number. How many actually, so how many people use Back of Immigrate? All right, so buy him a beer if you recognize him. Thank you, Ronan. And if you haven't used it in a while, it's got actually quite a few new features, depending on when you last used it. But let's just take a look at how it works. So we're looking at just a local website here in Drupal's sweet, sweet blue color. We're going to go ahead and just make a backup using Back of Immigrate module. There it is. Quick works. Now let's just go ahead and make a change. So simulating something bad happening to your website, we're going to do something trivial here, which we'll see what Ronan chooses to do. But if something bad happens to your website, delete the homepage, install the module, something goes wrong, site is hacked, whatever it is, there we are, bad. So let's go back to that backup and restore it. So let's go ahead. We're back in the Back of Immigrate module. We're going to look at some saved backups, including the one we just made. And we're going to go ahead and just quick restore. And we're back to the state before. Very straightforward. It works well. That's the point. Ronan has spent a lot of time over the years really trying to focus on making it easy to use, quick to use, and effective. And this is Back of Immigrate. Out of the box, this is exactly what you get when you install it. There's not a lot of configuration to do. There's not a lot of setup. And by default, it will clean out cache tables. It will get rid of stuff you don't need. So your backups are small. It's quick. The goal is it's one click to do a backup. So all that pain that usually is, this is probably about the quickest way to grab a backup for your database. Yeah. And we'll take a look at all the different kinds of, you know, the different stuff in here in a little bit. But let's just maybe talk a moment about. So Back of Immigrate. All right. So offsite backups. One of the things that notes or excuse me, Back of Immigrate does by default, like that basic initial configuration that the goal for Back of Immigrate was make this work on every Drupal site ever. So not every Drupal site has access to S3 or FTP or something else. So by default, it stores the backups locally on the server. And, you know, that's not a tremendously robust form of backup, frankly. If something bad happens to that server, the backups could also be compromised. And so one of the things that Roland realized after working on this project for quite some time was the fact that, you know, like we've kind of got a problem here. The module has the name Backup in it, but it's not as good a backup as it should be. And offering that as a service, actually, to be able to go ahead and get those backups off the server could be a really interesting idea. Because it's always supported FTP. It's always supported Amazon S3. It's always supported, like, other things. But all of those things are hassle to set up. You have to have an FTP server somewhere and you have to be, you know, like, have that out there. You've got to set up, you know, all the things. So reducing that friction to make it really simple to get your backups off site is what NodeScroll was invented for. So NodeScroll is at nodescroll.com and the excitement for us, this is a thing that Ronan invented as well. He brought it into, well, we don't need to go into the crazy story, but it was, up until last week, something that you had to pay for. And as of Monday morning, it is free. So the basic tier here is five gigabytes. It's going to handle a lot of websites. We're hoping it is, you know, at least 80% of all Drupal websites out there should be able to get by on the free tier. And hopefully that means you can now just not have to have this pain point or a potential pain point. So nodescroll.com, you go ahead and take advantage of that free. It will always be free. This is not a bait and switch. There's no credit card going in. One of the things we're really excited about with the Pantheon backing is that there's basically the financial wherewithal to make sure that this is available to everyone, everywhere. You do not have to be a Pantheon customer to use this. So it is there for all of us. And the evil plan from the Pantheon side is that Pantheon, excuse me, Pantheon wants to make great tools for developers and agencies. That's the strategic vision of Pantheon. And by doing so, if Pantheon has great tools, they feel people will like them and eventually do business with them. Very straightforward. It's what many of us do as a services business already. We try to do good work and if we do it well, you get more work. And so this is free for everyone, forever. So yeah, I'm gonna walk through what it looks like to sign up. Again, the idea here was to reduce all the barriers to getting a scheduled offsite backup for your site. So I wanted to make it as quick and as simple as possible. Obviously cost was a barrier that we've now eliminated. So I'm really happy about that. You can sign up, just go to notescroll.com and sign up. Or if you are within your site and you have the latest backup and migrate installed, there is a notescroll tab over here. And there's a link right in here. The secret key is your credentials for talking to the API. But right under here is a place to activate it to get a new secret key. This is the best place to go because your site already knows what it's called. Your site already knows your email address. That just lowers, it just makes it even simpler. I'm gonna create a new password. You guys should make it more secure one than that. But I'm gonna delete this account right away. Generate your key and that's it. Now, there's a copy step where we copy the key to the site that doesn't go over the wire for security reasons. So in this case, it's just copying and pasting through my local clipboard so that it never goes even over SSH. So this key should be pretty safe. I just copied it, hit that button to get back here, paste it in there. And as you'll see out of the box, it's sort of defaulted to some sort of good idea settings. You can turn this off, but automatically it'll schedule your database back to be backed up once a day and it'll prune old ones in a sort of a smart fashion so that you're not keeping daily backups forever. You're keeping, excuse me, daily backups for a month and then weekly backups for a year and then monthly backups for ever, something like that. So you will always have more of your more recent ones and fewer of your older ones, but you'll never lose the history. So default settings, the idea is those should be good. Those should be ready to go and click that button and that's it. We're set up, we're ready to go, we're ready to back up to Node Squirrel. If I just leave this running and Kron is running, it should start backing up every day. You'll get an email saying everything's good and it's working. I can test it here manually again. You know I have Node Squirrel as an option. I hit back up and it's gonna take a couple seconds longer this time because it is going over the wire to communicating with our servers and it's sending that backup file up to this Amazon Secure S3 storage and over conference Wi-Fi. Live demos, we all love them. There it is, so that took 20 seconds. That was way longer than normal, but maybe. That is, for something this size it's usually a couple of seconds. Obviously that depends on your conference Wi-Fi. This is all coming off my local, this is not on a server, so. That's it, it's now off site. It's in the cloud, if this site goes down, the backup is available on our site. You can download it from here, you can delete it if you want. You can take it to another server and it's just one more piece of security for when your server goes down. And it really is actually that quick to set up, so it's, again, goal is, or basically vision is, this is a best practice. 2015, we all know the importance of backups. We all know it's a pain to set them up, so that's why it doesn't happen. But now, hopefully we've dropped the barriers enough to actually just go ahead, just click the thing and then take the minute, maybe two minutes to actually just fill it out, take care of it. It's all going, it's the way we would want to do it for ourselves, which is very much the way the product was designed from the beginning, so it's all over SSL. This stuff is encrypted, it's good. The way it should be done, and we can answer specific questions if people have them. And I think that's basically, yeah, questions. It is, it's sent over SSL, so it's encrypted as it, at all points, in the transfer. And then it's encrypted on disk at Amazon S3 using their default on disk encryption. 15 minutes of your life. Thank you. Thank you.