 Good morning everybody. That was an excellent talk that we just saw from Brandon. Happy Friday. It's been a long conference Thanks for being here Friday hug to you all. It's if the house lights were up. I'd take a picture. Yes title this talk is The rails of JavaScript won't be a framework and the slightly less provocative version of that title is The rails of JavaScript will be more than just a framework My name is Justin We're not gonna have time for questions afterward. It's gonna be a very very fast talky slide-decky thing So please tweet me with questions feedback praise is always welcome at sorals and Critical feedback is always welcome at hello at test double calm This is talk about three of my favorite things one is cupcakes Two is the planet earth and three is monolithic application architecture so on cupcakes say that you own a bakery and a Customer walks in and they say they want something sweet So you bake them up a beautiful cupcake and they say hey, you know, this is really good But I like a little bit more sweetness maybe a little crunch So you put some sprinkles on top customers like digging the cupcake but says you know on second thought I really think I want something like with some hot fruit filling and then you just think to yourself as the baker Oh god damn it. What they really wanted was a fresh baked pie So you throw away the cupcake and you make them up high and that's not a mistake if it happens once But if your workflow as a baker is to assume everyone needs a cupcake only to have to inevitably throw it away And then bake something else. That's a real problem, you know for your business. So say you own a software studio and Customer walks in and says hey, I need a web application. So you say oh great What's its name so that I can type rails new and You build them a little graph, you know, you render it on the server and then they say hey You know this graph is great But I need some zooms and some filters and so you're like hey, you know I we can do that Sprinkle some JavaScript on top And then they say you know this is awesome But let's load all of the data all at once so that we the user can really really like just see absolutely everything at a glance Really dynamically like an app, you know, and then you the developer like I god damn it Because there's no logical path from that solution to what they really wanted which was a fat client JavaScript application I mean rails is probably still involved providing API services But it's not the center of the application that monolithic approach doesn't work And it's an honest mistake if it happens once but if part of your workflow is to Immediately assume that rails is the solution to every single web application And then you only realize later that you've built a gigantic mess with JavaScript. That's a problem The reason that I think that a lot of Rails developers fall into this trap is that rails is too convenient When you're a Ruby developer you have all these awesome tools right at your disposal We've got this great convention-based framework So I can just add a gem and it may be a couple lines and then I get all of this great behavior on the cheap And when I ask Ruby developers about their favorite client-side tools, they usually come up empty Nobody hates JavaScript more than Rubyists So they they just can't think of any and of course there's not like there's no client-side tools I'm just kidding. There are plenty of client-side tools available to Rubyists But this is their reputation right they're jagged and rusty and terrible So every time a new story comes down the pike we have to make a decision, right? Where's the best place for this to live? What's the concern here? If a user brings me a user interface card It might be that the best place to write that the best place for that to live is in the browser But the second thing I ask when I get a new card is like hey Where's what would be the easiest thing for me to actually do to build this take the least time be the quickest to market? And because rails is so convenient the answer is often rails So even though the best place for the code to live might be the front end I'm incentivized to start solving client-side problems on the server side and take into an extreme. That's really unhealthy So I have a provocative statement to make Non-rubyists write better JavaScript. I went to a dotnet conference my first dotnet conference last year in Sofia Bulgaria and I was blown away by how much we were talking the same language. We were using great brand-new No.js based tooling everyone was talking about and excited about Angular even ember But what my expectations were was it's dotnet. This is crusty You know and what I found in actually talking to people was because dotnet wasn't so incredibly awesome They didn't have that same moral hazard, you know, they were willing to solve the problem in the right place And when I think back in my own experience before rails was easy for me Whether that was before 2005 or when I was doing projects in other tech stacks JavaScript wasn't hard, you know, I actually really quite enjoyed JavaScript until I was told, you know to hate it and Granted we can have a long discussion We can have a Watt like screencast here of what is asking is JavaScript a terrible language and I'll just like clear the air, right? Yes, definitely. I spend most of my time in JavaScript. I agree. It is terrible, but I'm careful not to conflate that with hey well Is that why writing JavaScript is terrible? The problems I've always had with JavaScript have nothing to do with Watt I've nothing to do with map and parse in and fundamental problems with the language because I'm usually working at a higher level of abstraction Right problems. I have a JavaScript are all of the tooling the ecosystem the community So I challenge you to ask again later if you think the language is the one at fault After this talk, hopefully I'll be able to persuade you a little bit Let's talk about the planet Earth I Love Ruby and I love Ruby mostly for the community I love the language But I love the community because they changed the world when it comes to web application development If you were to chart all the great new tools for the web that have released over time Starting in 2005 the fantastic gems that were sort of the foundation for for Ruby on rails in this community Over time Hamel sass all these great extensions alternate stacks that we can have an omakase and a prime stack our spec You come are these great innovations helping us build better web applications the world it ruby Which gems became this mature marketplace of free stuff that would help us write better code, but then Right around 2012. I started to notice that when a new feature would come out for like say webkit It wasn't immediately followed by gems that would exploit it instead. I was finding JavaScript tooling written in JavaScript on node And that started popping up and then 2013 it really seemed to take off and you come to 2014 and a lot of rubies I think have this latent fear that JavaScript is going to devour planet Earth And I'm here to tell you that it probably will Where are the best tools if you were to ask yourself this you can add a add up a bunch of fact values For example rubies tool ecosystem. It's mature, but it's crowded There's not a lot of room for growth because everyone already has a lot of tools available that they that they love But nodes ecosystem. It's immature right it's innovative because so much new stuff gets pushed up and it's frustrating But it's great because as soon as a new feature hits a browser. There's a tool to exploit it I mean granted I get as frustrated as anybody else that when I run npm install on something Like by the time the install finally finishes at least two of those dependencies have probably had updates pushed But that's the fantastic so that's what I loved about ruby in 2006 and 2007 And tool authors they're not immune to trends I read a lot of like open source tools and I want to go where the people are I want to go where I'm gonna have a big impact And so tool authors are now gravitating to the world of JavaScript because the universe of people who have to deal with JavaScript is about seven billion people and the universe of people who have to deal with ruby is in the tens of thousands Yeah, all seven billion are JavaScript developers. I realize that's flawed Also tools that they address the problems of their day a gem that was written in 2008 Was written to solve problems that person was facing in 2008 not 2014 a tool that was written in 2014 surely must be useful in 2014 and so they're just a better fit for the web as it exists today Yeah, all that up and I'd you know, I really believe that web tools and node tend to better solve today's problems and This is maddening for those who insist on only using rails for absolutely everything But hey speaking of rails. Let's talk about monolithic application architecture Rails won the war right on web application frameworks It came in with a whole bunch of great reasons that we can go into later about why it was just the best It was it was fantastic and all these frameworks since then have adopted a ton of great ideas from rails But what we don't often think about when we consider that phenomenon is to ask ourselves Which war did rails win all web applications like generally or is there some subset of applications for the web that are a better fit for rails than others DHH last year rails content that good frameworks are extractions not inventions extracted from real applications and not just invented And so when you look at rails you obviously the story is that the company base camp made base camp and they extracted the good bits The common bits that they were seeing across a lot of their projects into Ruby on rails and Those kinds of bits that are common to many of us almost all web applications URL routing to point you to custom actions that you write Modeling behavior of the of the models in your objects the validations and all of that at a fundamental level persistence Storing stuff in a database querying for the stuff the relationships between stuff Session management in a way that's abstracted from where the session stuff is stored was hugely convenient Obviously all those ancillary concerns of the wheels that you don't want to reinvent like mailers And then there's this last little bit. It's like all these JavaScript alternatives There's sort of like the the means by which to sprinkle JavaScript on top Like Ajax ERB tags that dump a whole bunch of JavaScript into your On-click handlers in your in your markup or later on RJS or later on an obtrusive Ajax ERB tags or later on turbo links, right? It's not that those are bad that those alternatives are bad tools It's that they're there to solve they've been extracted from an application that just didn't have the problem of trying to solve and Write JavaScript in the way that I want to write JavaScript because if you consider base camp you started a page It's a traditional web workflow you start a page it click on a thing get another page a click on a thing get another page It's a it's a multi break process and that's represents a huge proportion of the web And that percentage of the web was almost a hundred percent in 2005, but it's much lower now If your app isn't a one-to-one mapping of like crud in a database and you're just exposing that as an interface to users If there's any layer of indirection you it might not be a good fit Yesterday Sandy Metz Made the comment as an aside that there are rails apps and then there are apps that use rails I'm finding that more and more the apps that I'm writing are apps that use rails I can love rails and not necessarily take advantage or really find a lot of benefit from the front-end aspects so rails promotes an HTML user interface in the front-end because that's what base camp needed and What I mean when I say that is stuff like you're writing HTML markup Like I have an anchor tag here with a with a ref and content or I might have a form action here with You know an input submit and when you're writing HTML like this It feels like you're making the UI, but you're not writing like UI programming What this is is the specification of a UI the user agent the browser is the thing responsible for figuring out how to render a link And what to do when you click it It's how to render a form and what to do when you know how to paint a button and so forth It's you're not you're kind of outsourcing the UI programming if you're building an application with the browsers your runtime though I'd call that a JavaScript UI and fundamentally the activity is just different and more complex You know you're responsible for finding the point in the DOM that you want to render stuff into or you're responsible for Binding to an event that the user does something and then you need to take some custom action You're the one in the driver seat. They're fundamentally different concerns but our tools I think file I like tree to tree stuff out because I think that tools tend to Betray their biases based on the layout of the files that they give us You know naive rails that might look like this and it screams MVC and it screams server side But of course in reality One of the kind of like you know dust bin corners is that we have this this ghetto right under assets and then the most You know unfortunately name directory ever JavaScripts and then application JS and it's telling us all this stuff at the top this matters And this thing at the bottom just write one big long Bola spaghetti and it'll work out and that's how a lot of people right, you know JavaScript and Rails application still Some people though that's not good enough So they they they realize that they need to write more structured JavaScript And so we end up with this new thing like an HTML UI and a JavaScript UI combined and you might notice a pattern here, right? there's a An MVC in the back and then it's also MVC in the front it makes command T really difficult, but it you know we see this duplication of back-end concerns and front-end concerns and There's also this this little Nagging doubt about do we really need this views here right if we're building a full-blown fat client JavaScript application The back-end views are that rails provides just are less useful so those often get cut out now and We we just have sort of a JSON API in rails and then this deeply nested JavaScript UI And so at this point if you like a new person comes to your project and they ask hey So what exactly is that thing right? I would call that a vestigial appendage Because it can only be explained in terms of the past you have to pull up your you know forensics of like well in 2008 We were all you know thinking this and now it's still like this What's wrong with that vestigial appendage? Well, what's fundamentally wrong is that a Fundamental problem in in programming is that we move way faster when we can fit the whole application in our head at once And when on day one of any project you can fit the whole thing in your head at once But on day 1,000 of the project that's probably not going to be true So if you build a monolithic thing up front as that app gets bigger eventually you reach a point where you can't fit it all On your head and you start to page right part of the application that you're working in you can think of and then over here You start to have to page out and if you don't modularize things well Then that that that thrashing is really really risky because it might mean that like I'm in this part of the app And I just kind of have to hope that my tests are going to cover me Although by the time you're this big your tests in our typical rails ever get 10 hours long So maybe tomorrow you can find out that it worked But if you via common concerns and find a good module point to to separate on If you were to identify that you could have like a front-end app and a back-end app as those two things grew Even if the net complexity is higher at some point, they're not going to fit in your head either But the paging story is much nicer because they have a clean well-defined separate contract So the application that you're working in the back-end application if you have to work in it You can work in it and then when you page out it's not thrashing because there's a clear understood contract between the two Relatedly I like to say that late extraction costs more than early abstraction yesterday Sandy's talk was great at telling us about wrong Abstractions that have been found and it refactoring away from those but when we've seen the same project a dozen different times I would much rather extract Seldom and and and abstract early and that's really confusing sounded so I'm gonna talk about yarn now Imagine you have two balls of yarn If you decided like man, I really just wish instead of these two ugly balls of yarn I had a big knot of yarn all tangled together. That's really easy to do thanks to the basic laws of entropy But if I have a big tangled knot of yarn and I decide that I really would love to nicely bald You know the nice balls of yarn turns out. That's very very difficult to do That doesn't work So that's why what I mean when I say that late extraction all these like fancy refactorings that we can do costs a lot more than just knowing you needed two things in the first place so Back to this this two step that I seen a lot of Rails applications where in one project You've got the json API, but you also have all the JavaScript. This isn't problematic until you consider This kind of stuff you you have a template that renders a script tag at the top and then in the ERB Certain bits of data are kind of taking this sneaky back door instead of actually using the the proper API To just dump data into the JavaScript application needs when you see this it really means your yarn is tangled Right, even though you think you have separate things and your API is a lie because it means that even though your application is mostly using That API if somebody were to come and say hey, I want to build a mobile app for your site They're gonna have to spend a month figuring out how to get that token, right? But it's hard not to cheat and I agree It's very very difficult especially given what we talked about earlier where the tooling is so bad So my objective in the last four years of my my open source contributions and now at test double Where we spend a lot of our time we want to help make JavaScript apps easy as easy as Rails When you think about rails and the responsibilities of rails There's really three distinct parts. We have an application framework stuff that we extend action controller and so forth We have conventions and configurations that are laid out for us that we learn through the community and the documentation and we have build automation stuff like like a Rail CLI and rake and rails owns the whole stack If I had to grade them separately, I'd say that rails as an application framework when I first found it I loved it, but I found on like many year five year six year projects It encourages a lot of things that are problematic So maybe I'd give that a b-minus if I was grading it separately, but the conventions and configurations That's awesome. I love that I can hit a new rails teams project and because of the tribal knowledge that we have as well as the conventions laid out and the Sensible defaults. I can see how is their app different from the norm really easily The build automation stuff is pretty good. I think it's gotten a little bit stagnant fantastic in 2005 And I haven't seen a lot of really cool stuff lately, but still solid What I really want to talk about today is convention and configuration and the value that I can bring to our JavaScript tooling Also keep in mind that a lot of people who are new to rails or have only ever worked in rails just see one big thing They don't see these as separate problems So if that's you try to think about these responsibilities separately because I think they can be solved by separate tools for example in JavaScript Application frameworks are everywhere if I decided I want to solve that middle problem by writing another application framework Then I'd have to you know go and popularize it against all the other application frameworks I think that they can be separated, you know, whether I'm writing backbone or angular or ember lately I've been writing a lot of ember and I love it But every six months I keep changing my mind. It's a fact. So so at this point I just want to be like eh, I want to write awesome tools that are framework agnostic that anybody can exploit From the build automation perspective Like I said that the community is already in node.js worldwide as soon as stuff is happening Great tools are showing up in node.js first. I just want to be this little guy in the middle, right? I want to be the convention the configuration and that's why we built lineman Lineman like a like a lineman on a railroad is on Twitter here, and you can find a URL And you install them with npm. So you have node.js installed and you can just say npm install globally lineman And you create a new app really easily with the CLI just like rails lineman new app So here's me typing in lineman new Starting a new project and I get a little I get a handful of commands That I can run but first I'm just going to cdn I'm going to tree out all of the files that I have Like I said it betrays the biases right you one way to learn the conventions to see what it generates So you can see I have an app directory with CSS and images and JavaScript and then pages that render on the back end and templates on The front a handful of configuration files a whole bunch of spec helpers to help you test and then places for all your Vendored third-party libraries and it's convenient right it's nice to get that bootstrap for you But our goal is to make it convenient throughout to switch between projects to reduce duplication to make things more common across all of our work One aspect of that is our productivity workflow I want to be able to write some code save the code have that code automatically compile for me every time I save have it concatenate for me every time that I save and then I want to be able to Command R and refresh and play with it But I want to be able to do all of that in less than a hundred milliseconds because I want a fast feedback loop So that I can keep working quickly in lineman We do this with a command called lineman run so you say lineman run it does a whole bunch of initial build stuff But then it just starts watching for file changes so I can hit the server the dev server. It says hello world I'm going to make a quick change say goodbye world It's already updated. I refresh the page and that's that now This is a simple app, but even on large apps. It scales very well on our largest applications. It's still roughly a hundred milliseconds So this is great But command our driven development isn't the whole story, right? I also like to write tests Sometimes I'm doing test-driven development when I do I also want the same story to fit slot in really nicely with with tests I want the same feedback cycle to be super duper fast lineman ships with a cool tool called test them written by Toby Ho That's really fantastic. What you do is you open up another shell a second shell and you run lineman spec and you get this interactive test runner launches chrome here and Here I'm running a test already Gonna just change the spec to say that I'm specifying that that function return goodbye world Save it off got a failure that quickly. I can debug because it's in the browser But I'm just gonna fix it save and I'm up to my tester passing In addition to the interactive runner, we want a really solid CI story So you just quit out of test them with the Q key and you can type lineman spec CI And this will gonna run it all in phantom js with a nice reporter output And every lineman project generates a Travis YAML file when you lineman new So you literally just push it to github and if you use Travis as your CI service It's a one-button thing and now you have a CI build for your JavaScript Which if we were to ask people to raise hands, I don't think every hand would go up if I asked if you have one The deploy story is similarly easy because since lineman is just a static asset generating tool Can your server host static files? Then yeah, you're good When you run lineman build and then you tree out its disk directory, which is where it puts its built artifacts It looks a little like this out of the box You're an HTML file that references a CSS file and a JavaScript file and both of those have already been concatenated and minified for you And they're ready to deploy There's a single flag in the config that you can set and then just like rails you get asset fingerprinting It makes it really nice for deploying when you have a CDN Everything else that ever is gonna end up in your disk directory is gonna be stuff that you added So it'll be stuff that you understand. It's a really easy build story Pushing to heroku is also really easy. We host most of our testable stuff on heroku So we just set we wrote a custom build pack you set that up and then you say get push It'll build it with node js But then at runtime we don't need it and so it just runs statically without node And we also have a whole bunch of starter projects to help get people up and running quickly Not everyone's just writing vanilla JavaScript, right? We have some people who want to get started with angular quickly backbone or ember You just clone and go clone the project and get started you have a little bit of example code It's a great way if you want to learn angular or learn ember just to clone our example project because it'll build right away Like you already know how to run it We also have Really cool. It's because it's so flexible. We also use linemen to build all of our JavaScript lives that lives that we Maintain as well as our blog and and you're free to use linemen of course to write a markdown blog It's really really convenient So back to planet Earth We're using grunt. We grunt is a is a build tool Descended from you know a whole bunch of other build tools that that is used for task definition There's a lot of different there's a lot of competition here right now in node js a lot of people using gulp Thing called broccoli came out recently. It's really cool But what we use grunt for primarily is a place to get awesome stuff from the community all these tasks ship with linemen Out of the box or our and so many more are available We really really love that we're able to so easily pull in a New behavior through grunt in a consistent manner linemen itself is comically Extensible we have a plug-in system that's built a little bit around this Mental model we'll talk about in a second, but it's really easy from a user's perspective All you do is save it npm install then you save the save the dependency run like linemen bower When you do that after you run linemen run the next time after you save that linemen will pick it up from your package Jason know that it needs to load it and bower will be slotted in at the appropriate step in your builds workflow No more configuration. It even generates your bower Jason for you if it's not there Because deep down there is an npm module out there bower right published by Twitter and around it is they a Grunt bower task that somebody in the community published and then at the top we have this linemen bower plug-in that we maintain Bower is the thing that actually does the thing that's where most of the hard work is This this bower task here from grunt it automates the thing. There's a lot of hard work there, too What linemen does is it just knows given linemen's conventions how to configure the thing for you And so we have this kind of boxed approach to how we conceptualize plugins So you in your application you might have a linemen bower plug-in that you use But you can also have a linemen ember plug-in that's going to handle all your templates the way that ember Likes to see it and recently we we learned and we're really excited that rack space is adopting linemen for its front-end development And I encouraged them to write a meta plug-in because you can have recursively arbitrarily many Plugins down the line. So this plug-in here name it whatever you want Maybe your company's stack or something it can bundle as many plugins at the appropriate versions that you want But you can also override any of the configurations of those plugins and get them just how you like that We don't have all this duplicated configuration across all of your teams file teams projects Back to monolithic application architecture. I've painted a picture where we can separate into two things But I want to talk a little bit more about the benefits of doing that So say that you have a client in the server one of the first questions that comes up is like hey Well, how am I going to run stuff in development, but it still needs to see the server I'm not going to build all these extra stubs for my server side and we agree that would be really onerous So we built a feature into linemen that we call API proxying basically think of the browser hitting linemen And maybe we'll have a Sinatra in the back end The browser is only going to know about linemen. It's going to make all of its requests to linemen But whenever they ask for any API routes that linemen doesn't know how to respond to we've got it configured to call back to Sinatra Sinatra responds and then linemen proxies that request back to the browser So it's a seamless environment It's as if you're developing in one thing at runtime even though the code has all the benefits of physical separation Looks a little bit like this. So I'm here. I'm going to uncomment a little bit of configuration that we give you Change the port to four five six seven For Sinatra My application is real simple. It's just got a simple route high it gets it and then it paints it onto the screen whatever the text is and Nice and not wrap just returns. I heart Ruby at that particular route So when I write linemen run You can see it said it's proxying. I'm going to look at Sinatra's logs I refresh and it got the request from linemen and it returned through the browser super easy Now there's other cases too because the benefit of separating front end and back end a big part of that story is that now Development of those two things doesn't have to run in lockstep, right? We can make a little bit of extra progress in the front end Maybe do some prototyping we can have a separate back-end team after we get big But a lot of times we had like, you know It'd be handy to be able to stub stuff out that doesn't actually exist on the server yet So we can get faster feedback cycles while we're developing our front end And we offer this in linemen with a tool that we called API stubbing so same situation We have a browser and it's going to be hitting linemen and Instead of actually phoning through to Sinatra We're going to kind of stub out a particular route and prevent Sinatra from getting it and we're going to return that stub back to the browser So same same exact code base. We're going to go into config slash server JS This is a an express application. That's just kind of bundled in we can define any route We like we're going to overwrite that high route and we're going to we're going to troll our coworkers here by sending that We heart node even more sacrilege So run linemen refresh the page and now our stubbing is in place You can build entire toy applications inside of that express application. We've had clients in the past test double as an agency And so we're as consultants. We've had clients in the past who've asked us Hey, just give us a specification of the services that you want and our specification is a living document of well Just make it do this and it's been a really really seamless. It's certainly better than a traditional documentation Another case that I like a lot is I had a project once with a 30 minute long test build And I split it up into a split the application up into two front end and a back end just like we're talking about Then I went to recover that new application with tests I found that the front end tests had a runtime of only four minutes That made me very worried about the state of affairs in the back end I figured that might mean that the 26 minutes was hiding there somewhere But as it turns out I wrote that and that only took four minutes, too So then I got really suspicious and I'm like I should probably have some smoke tests that make sure that when this is all plugged into Plugged together correctly. It works and the smoke test of course when you plug in them both It's a little bit slower and that ran in a whole two minutes So this 30 minute test suite somehow got reduced to a 10 minute build even though the net the logical and physical complexity of the system increased and if you understand how build duration tends to grow super linearly any Savings that you can get up front in the beginning are going to mean a big difference. You're gonna get a lot longer Runway and traction out of that build suite in the far future And additionally it's habit for me, right? I mean having a There's a lot of operational problems that you have to solve when you have two different things to maintain and manage and version As a deploy story two different projects you can make it simple, but I mean once you solve that problem Once you can have arbitrarily many micro services popping up And if you're viewing the world is going in that direction It's a great problem to solve now with a problem that you already understand really well front ends and back ends Additionally, this is not a front end versus rails talk. It's an and we love rails We use rails all the time for our services and Lyman and rails play together really nicely We've got a gem called rails lineman and a lineman plug-in called lineman rails You install both those things and you just Magically everything gets auto-configured and and your development story is great and assets pre-compile is just wrapped with a lineman build first You can learn more about that at linemanjs.com slash rails.html and we have this fantastic little Documentation site put together for us by Derek Briggs from Neo More recently you can actually see me do this myself live coding unedited In an ember screencast that I did how to get set up like we would set up a project and that set our blog It's the current most recent article. So just hit the blog test double calm and you'll see the the embedded screencast It's a fantastic tool. We love working with it. I Also real quickly. I just want to thank my friend Marissa. Heil. She's a visual designer who's available for contract She did all of the good illustrations in this talk and and you know We'd love to help you if these are problems that are that are that are new and hard for your team Let us know you know We are consultants and we'd love to like engage with your company and and and work on great stuff alongside you But we'd also just love to answer your questions because I think we want to all make an impact and move the move the conversation forward Also, like everyone else at rails count. We are hiring Just send an email to join at testable calm and we'll respond to you promptly and have start the conversation also a couple of my fellow double agents Todd Kauffman and Zach Briggs are giving a workshop this afternoon on JavaScript testing I think they'll probably be using lineman So it might be a good place to practice both of those things And I want to thank you, you know, please reach out. I'd love to hear from you It was an absolute honor and a privilege to get to speak to you today. Thank you very much