Emmanuel [00:00:00]:

It's such an honor to have you on the show. Welcome to the real exchange log. David.

David [00:00:04]:

Thanks for having me on. Sorry I'm a little late here. It's a little early in the morning over here.

Emmanuel [00:00:08]:

Yeah, that's fine. To start the show, this is a personal one. Just a few days ago, I noticed you changed the name Mrsk. To Kamal. What happened?

David [00:00:25]:

It yeah, so there are sort of several reasons and then there was one big reason. Some of the minor reasons was the fact that quite a few people found it hard to pronounce. And that was when I kicked this off. I was interested in making this tool. And when the initial web page went out, I don't know if you caught it, some people did. It was just a plain HTML page. There was basically an H1. This is what the name of the project is. And there was like a couple of paragraphs of text that is I didn't put a lot of effort into neither the naming nor the presentation nor whatever. I was simply excited about sharing this tool that we were using for our cloud exit. So in retrospect, perhaps I should have thought a little bit more about that name. But then due to other factors that I've been advised not to go too much into, you can probably extrapolate from there. It was just, all right, do you know what do we really want to do this is this name that important? And I was like, no, it's not that important. First of all, the name does have these minor issues like being hard to pronounce. And then second of all, I don't really care. I don't really care. So this is something else. We have Rails, for example. If someone came to me and said we should change the name of Rails, either because I don't like how it's pronounced or because there's some other issues with it, I'd be like, yeah, there's no way. I am deeply committed and connected to that name for 20 plus years. Here's a little side project that I just made happen in a couple of months. Not connected to it at all. We ended up with this new name and the beautiful part of it was it took, I don't know, 2 hours to just roll through and do the rename after they actually it took longer to come up with, you know what? If we're going to change the name, let's come up with something good that has a connection to what we're trying to do. And I was looking at all these terms within seafaring and all the obvious ones are taken, right? I looked at the place names for a while, like Panama or Suez or something else that gives the connection of containers being shipped in a better way. All that stuff is, of course, taken. That's the nature of the world we live in. Certainly any single English word is already occupied by something. But here was a wonderful Arab word. It's also a Hindu word. It's a Turkish word if you spell it differently, meaning all sorts of different things in different languages. But what I got attracted to was this idea of the Kamal being one of the earliest navigation tools and being such a simple tool, yet actually quite sophisticated, right, that you can determine your latitude and actually keep your course just off a plaque card. It looks like those old school CRC cards people would use to design object oriented systems. And then a string that you tie a knot on and you hold it in your mouth and you measure against the North Star. That'll give you your bearings, I thought was in many ways the perfect encapsulation of what Kamal is trying to do. It is not a sprawling, sophisticated, Kubernetes like orchestration system. We don't even use the word orchestration to describe it at all, because it's not that complicated. It's taking a piece of software, wrapping it inside a container. It doesn't even wrap it inside a container. Docker does all that mal, just takes the container and then puts it on a number of servers and executes a couple commands. That to me, felt like a piece of board with a string that you tie a knot on. It has the same level of simplicity.

Emmanuel [00:03:57]:

Sounds like a very fitting name for a tool like this. When I saw the name change, I was surprised that the name change came just now. Why not earlier? What happened? What's going on? But to be honest, I didn't like the name. It's not like I used the tool, but I didn't like it. I wasn't sure. Is this an acronym?

David [00:04:17]:

That was part of the problem, right? It was an acronym managing remote server containers, but not enough, and especially like the pronunciation of it and so on. Let's make it more difficult than it needs to be.

Emmanuel [00:04:31]:

The most important thing, I think, is that we have a tool in our ecosystem that we can use to deploy applications. The name is not so much very important as the tool.

David [00:04:43]:

Not at all. And that is what I'm so pleased about with Kamal, that this was, to me, something that was a real lack. We had all these commercial offerings. Heroku for many years was just a gold standard, and for good reason. It made deployment so much simpler. But do you know what? I think it's been a decade since Heroku was bought by Salesforce. And while there's been other commercial offerings that have taken up the mantle of more innovation, like fly IO or render or other things that seem like they have a little bit more life in them to push things forward, it felt wrong that we have this wonderful open source framework that prides itself on being full stack. Yet there wasn't a great open source answer to how do you get your application deployed? There was for a while, right. Kamal is in fact an extension of Capistrano. Capistrano was the original deployed tool, but it wasn't built for the modern way of packaging applications. It was not built for a world of containers. And I think this is one of these things that get me really excited after still 20 plus years, is that we can get these fundamental improvements of technology like Docker that actually doesn't make our life, if we use it right, more complicated. It is a leveling factor that we can build something simpler on top of. Now you can also build something far more complicated. Kubernetes, for example, is obviously built on top of containers, and so are a lot of other tools that have orchestration in their tagline. And I have looked at a lot of those things. We've used a lot of those things. Simple would not be the word I would use to describe them. But the underlying technology, the container ionization technology, actually is a simplifying technology. So if you just find a way to package that correctly, we can end up better off than what we were before. In terms of conceptual overhead, that's the stuff that really has me excited. Whenever I see a breakthrough like that, and I fully admit that see a breakthrough. I think Docker is from what, 2009 or twelve, or it's really quite old.

Emmanuel [00:06:48]:

And yeah, it's been around for quite a bit.

David [00:06:50]:

A long time, right? But this is also one of those reminders of the pitfalls of running something for a long time, because when you have something that works Capistrano for us, for example, we still use Capistrano to deploy Basecamp. Right? Now, Basecamp, one of the versions of Basecamp, I should say we have several versions of Basecamp. Some of them are on camel already, some of them are still being deployed with Capistron. And it's the kind of system where it works. Why tinker with it? Why bother it? But I think in that analysis lies stagnation as well. If you constantly go, it's good enough, we don't need to dig deeper, because then it would be a hassle to change. You end up just Ossifying, and I don't have any interest in Ossifying. So really exciting to me when we can take some of these fundamental blocks that actually work well enough. That's the interesting thing. It's easy to identify a piece that's totally broken or just totally out of date and say we need to change this. It's far harder to take a piece that's actually this is good enough, but we could do it better. I want that spirit for myself, with our business, for Rails, that we continue to look at the tools we have and go, you know, what sort of good enough is not good enough? If we have better ideas, if we have insights that can lead to conceptual compression, we should employ them now. We should employ them in reasonable ways. We shouldn't just throw everything up in the air I think people who are old enough to have gone through the Rails 2.3 to 3.0 transition probably still have scars from that memory. And obviously there's been plenty of other cases. This Python two to three, you can sometimes go, oh, here's an improvement that's so important that everything needs to be rewritten, that I don't have a lot of patience for, because I shouldn't say patience, I should say appetite, because it just seems unnecessarily abrasive and it has this tendency of splitting community and all these other things. So Kamel is easy in that regard because it doesn't require you to rewrite your application or whatever. But there are other things coming in the Rails world. Prop shaft, for example, a replacement for Sprockets is something I've been involved with developing and that we have our eye on. Taking the seat in Rails Eight, that becomes the new default. That has more complications, perhaps, for existing applications, which is why I'm so committed to what we have to be able to make it fit at the same time. So if we want to run Propshaft, for example, which I do, I think it's one of those simplifying tools that come off the same foundation as Kamal, that there's something there's a piece of technology that's hugely simplifying, and http two so HTP two really upended everything. Web developers ought to think about bundling and assets and all this other stuff because suddenly there was not an overhead for sending 100 files. How you manage transition of change is really important, especially in a major framework like Rails that has been around for 20 years and literally has million plus applications developed in it. You can get so infatuated with employing your latest thinking in a way that really makes it difficult for people to follow you, which makes it difficult to upgrade. I think anyone who's upgraded Rails for the last several versions had a pretty good experience. It's been quite smooth for quite a few versions because we've really, first of all, because we've solved such a large part of the problem domain, but second of all, because there is this commitment that, you know what? If we totally change everything, it's going to be difficult for me to upgrade the older applications that I have. It's going to be difficult for Shopify, for GitHub, for Intercom, for any of these other long term community actors who just have a lot of code already written on it. But at the same time, we cannot let that be a justification for stagnation. We can't just say, okay, we're going to live with the best ideas we had in 2012. No, then I'm not interested in being here anymore either. Neither are anyone else who really wants to work on pushing the framework forward.

Emmanuel [00:10:48]:

We'll get to the bit about the intricacies of the Rails's timeline and the difficulties that we've overcome and the tooling around it. But now I want us to talk about the Rails Foundation if you go on Rubyonrails.org on the foundations page. I'm not sure if I can call this a tagline, but rails foundation, and I quote, is a non profit organization helping our ecosystem prosper. It has eight founding core members and a very convincing mission statement with, of course, a very wonderful executive director, Amanda Perino, doing a lot of good work. I want to know, I think this is the time for me and a lot of people to know, how did the eight founding members get together to create the rails foundation?

David [00:11:46]:

Yeah, so the rails foundation is one of those things where it retrospect, it seemed. What took us so long. Rails has been this major framework depended upon by so many companies, billions of dollars of enterprise for so long, yet hasn't had a backing organization that could help us push some of those things forward, like documentation and so forth. So in the one hand, it's OD that it didn't exist for the longest time. And then on the other hand, it's like, exactly. Why now? Right. There are several factors to this. One thing being coming up on or I could see at the time, I started thinking about, like, 20 years. 20 years is a long ass time. That's half my lifetime. That is an example testament to the fact that rails is going for the long term at some point. And perhaps there already are in certain quarters. Like, rails is going to be cobalt. Just like anything that have reached escape velocity in terms of adoption is eventually going to be cobalt in the sense that there's going to be a ton of systems built in this even if we 20 years from now. 40 years from now 50 years from now have come up with much better abstractions or tools or technologies or whatever that warrants an organization that kind of has the long term interest at heart that's beyond any one single person. Now, obviously, I'm personally very tied to Ruby and rails. Not only am I the creator of Ruby and rails, but I've also been actively involved for the past 20 years. I continue to just find joy in making the framework better, in interacting with the ecosystem, in seeing it prosper. But if it was my company and we had one person who was responsible for a ton of things, and we went, what's the bus factor on this part of it? First of all, just I mean, I'm 43 now. I drive race cars. I live under the same mortality curve as anyone else does. Do you know what? None of us is going to get out of this alive. None of us is going to live forever. If we want to establish ecosystems that go the distance, they should have a bus factor that's greater than this. So I wanted a bunch of this stuff that I often was doing or involved with or helped coordinating live inside an institution where I was still involved, but the institution could outlive me. So after all of those realizations and some of that also just whatever the squabbles we had with other conferences and all that mess, it was just instigating factors. There were all these things. There was all this momentum that had always been there from, I don't know, from rails was maybe three years old. I think we got the first approach. I think it was from the Apache foundation. Hey, do you want to join the Apache foundation? We have all these setups infrastructure to help you do things. And at that time we're like, no, maybe not. And then over the years, we thought about it several times and went, you know what? Maybe we should have something. It just never happened. And then all these little drips come together and we're like, all right, let's do it. So I basically went through a list of all the companies in the ecosystem and went, you know what? If I was going to put some work into getting this foundation off the ground, who'd I go to? Who'd I ask? And it's more or less the list that you see where I go. Do you know what? GitHub and shopify are the two largest corporate pillars that we have in the community. They've both invested heavily into both Rails and into Ruby. Do you know what? Let's go there first. So I went to topi first, partly because Topy has such a unique history, partly because he's such a good friend of mine. He's been on Rails core, and now he's the CEO of this enormous billion dollar company that continues to invest heavily into Ruby and Rails. And it didn't take much, thankfully, for me to persuade him that shopify should join. And after that, kind of the ball got rolling rather quickly. Talked to some of the other members, and at some point there was enough first. This was like exploratory, right? Is there even an interest? Are there any other companies who can see the same value in having a foundation as I'm seeing that we should have an organization that's our own, that we're not borrowing resources from other organizations that have different charters or have a broader remedy or whatever. There should be an organization for Rails. And quite quickly that was, okay, yes, there are other people who see the same things. There are other people who are invested in the long term future of Rails. So there's interest there. And then it came up like, all right, there was almost like, backwards. If we're going to have board meetings where the founding members are present, like, how many people do you want in the room? I don't want to sit with 22 people in a thing that seems like too much. Eight sounds good because eight also divides a million dollars, which was the number I had in my head for an initial treasure for the foundation to kick off. Like a substantial number that meant business, that we could do things that we wanted to do with. Do you know what that's one hundred and twenty five k. I need to go around asking these eight foundation members. That's a substantial number, but it's also not like a ludicrous number. It felt like it was doable, and that was basically how it ended up. I did just a lot of that initial running around, convincing people, selling the vision of what we're trying to do, which really didn't require much selling, as you say. When you read the mission statement of what is the foundation interested in doing? Promoting the documentation de education, the marketing and the events in our ecosystem. Oh, yeah, that sounds like a terrible idea. What? No, it doesn't. Of course it sounds like a great idea. It sounds like something we should have had for a long time. And now we do.

Emmanuel [00:17:30]:

Yeah. So that brings me to another thing that I was thinking about. If I look at conferences, ruby on Rails conferences in the states, and I look at Rails World right now, for me to go to the states, I'm not even talking about flight tickets. I really want to connect with people, rails programmers, Ruby programmers, but tickets out of the way. The ticket to get into some conferences inside of the states is a bit enormous for me. It's like it's too huge. But if I look at Railsworld and I look at how much the tickets for Rails world is going for, I start to think, how is the foundation able to pull this off?

David [00:18:19]:

That's a great question, and I think one that really helps define what the foundation is and why it does, the way it operates, and especially how we were able to price the conference in this way. Conferences are not cheap. Conferences are very expensive, and they take a long time. I think I even underestimated with this conference just how much work would be in it, and it's Amanda doing the vast lion's share of it. What we wanted from the foundation's perspective was this is a nonprofit, and part of being a nonprofit is to maximize the goodness of these goals. The documentation de education. Let's just take those two points, right? Every material confidence produces documentation. It produces sessions that illuminate parts of the framework or whatever, especially this Rails world. I don't know if you've perused the speaker list, it's just like if I was going to put together an ideal introduction to what is modern Rails like, it would be that list, right? So there's that, and then there's the education of being there and being able to these are the goods we're trying to produce, which means we don't have to make money on the conference. In fact, this conference is going to lose money. The foundation is going to eat a fairly sizable what always happens with a conference is you take a risk. So you incur all of these costs up front, and then you hope that you're going to make in some cases, that you're going to make it all back, or that you're going to make a profit because you sell enough tickets. We had a different approach. Our approach was we just want to get close to break even, but we don't even have to get break even. From the latest estimates that I've seen, the foundation is spelling well over $100,000 just eating it in cost to keep the cost down. Now part of that is because this was the first conference, we wanted to make sure that there was enough. It sounds silly in retrospect demand. Like are people interested in the Rails conference in Europe? And then literally they go on sale and like 5 seconds later all the early bird tickets are sold out. And I think in less than 45 minutes we sold all 650 tickets, which it's one of those things that's hard, right? So when you do anything commercial, you can ask people, would you like to buy this product? And tons of people would say, yeah, sure, sounds like good product. And then you put it for sale and no one shows up and no one buys. Right? We had a little bit of that. We knew there was a ton of interest and enthusiasm for a conference, but we didn't know exactly how much. Right now, clearly we underestimated. If we knew now that we could sell 650 tickets in about 5 seconds, we probably would have made a larger conference. But that would have meant a larger risk. And we were like, you know what, let's just take it prudent. This is the inaugural Rails world. We don't have to do everything right away and we certainly don't have to risk everything right away. So that's how it come together. We don't have to make money on it. In fact, we're happy to lose a bit of money on it. But we don't want to take an existential risk for the foundation that suddenly we're on the hook for a million dollars and no one showed up to a conference or whatever. Thankfully, all that now has been cleared away. So the next Rails world that we're going to do is going to be a lot easier for us to organize because we know that there is a groundswell of support. Maybe the tickets are going to be marginally more, but they're going to be nothing like the professional ticket sizes that other conferences, even other Ruby or Rails conferences sometimes end up charging. Because if you need to make money off a conference, you just charge different things. So we want to keep this as open as possible that the ticket price itself should not be the main limiting factor. Can we do it for exactly as low of the ticket price as we did for this one? Probably not, but it's not going to be that much more. And I want to make sure that it stays in such a way that Rails world, like Rails itself, is something that's accessible to a person who goes, do you know what? I want to learn rails. I want to get into Rails. I want eventually to get a job in Rails. I'm going to self fund my time, my resources to get an education in this. And it's not something that's going to totally break their back or their bank. Now all we can really talk about is this conference because this is the thing that's actually happening. But of course, we're already going, oh, for 2024, what should we do? The other thing here is it's called Railsworld for a reason. And part of that reason is that I don't see this is not a regional or even a national conference. This is a conference that can move around. We can go different places. We can be in Europe, we can be in North America. We can theoretically be wherever we want. And there's even sort of just inklings of thought, you know what? We also have some smaller conferences that are associated with Rails world, but there aren't these big, massive productions that Rails world is. There's so much more we could do. But I'm just really happy that the first thing the Rails foundation puts on is not just like a success, it's just a bam, like where even other language communities took note and go, holy shit. What? Rails can sell out 650 tickets in less than 45 minutes. I think that's the kind of statement that is just good to make for the community, for the ecosystem, and for the foundation.

Emmanuel [00:23:31]:

What is the role of 37 Signals in the Rails Foundation?

David [00:23:36]:

37 Signals is one of the eight founding members, fully paid up as anyone else. And Rosa, lead programmer at 37 signals, is our delegate to the board. The way the Rails foundation is set up is that each of the eight members nominate one employee. It has to be an employee of the company to the board, and that constitutes the main board. And then I sit as chair of the board, and then we have Amanda as our executive director. I, of course, have a little bit of a dual role, if you will, given the fact that both I'm part of 37 Signals, but I'm also the creator of Ruby and Rails, and I'm also the chair of the foundation. But we've separated that out as best we could. As in 37 Signals still needs to contribute in just the same ways that every other company in the foundation is doing. And in that regard, it's not more special than such. The specialness around the arrangement comes into the fact that I'm both part of 37 Signals and I'm also the chair of the foundation.

Emmanuel [00:24:34]:

I'd like to tell you now about our newest sponsor, app Signal. App Signal has been around since 2013, and they offer a comprehensive monitoring for Ruby applications, including error tracking, performance insights, server metrics uptime, monitoring login and so much more. App Signal is easy to set up and works seamlessly with all popular Ruby frameworks. It automatically instruments and creates beautiful dashboards for Sidekick, active Job and other integrations. Visit appsignal.com to learn more. And be sure to stop by Appsignal's Booth at the Realsworld conference in Amsterdam this year. Now, five years ago, and after seven episodes, you were doing these series on YouTube that, from what I know, you've moved the whole series from, I think, your personal channel to a new YouTube channel that's called Getting Real that people can subscribe to and see more of what you're doing with base camp and hey, and 37 signals. People seem to like the series a lot. On writing software I think I watched two or three episodes. I really liked it, but later on, for some reason, I couldn't find where I could find the other episodes. Do you have any plans to revive the series, to bring back the series and continue creating more content around that?

David [00:26:08]:

Yes, absolutely. And it's amazing when you say it's been five years, because it doesn't feel like it's been five years, but all of these things happen. Pandemic and so on is compressing and screwing with the sense of time for all of us. But I absolutely want to reboot the series, or not even reboot this series. I like to think of these series as seasons. I did season one and then we just had an overly long break and now there's going to be a season two for sure. The first episode I want to do is the one I promised in the original season so long ago on Delegated Types. So Delegated Types is the most consequential and important architectural pattern that we use at 37 Signals. In fact, we had just started a new product development, and again, delegated Type is the thing that just comes in very early on and makes so much make sense. Not just makes sense, but provides a harness of how do you structure the application, how do you hang things together, what are the main arteries of queries and so forth that you need to do? So Delegated Types is the reason I will restart the series, because I just feel like it's such a shame, and it's shame on myself that we came up with this pattern. We saw just how insanely powerful and versatile and maintainable this pattern was when Delegated Types was introduced in Base Cam. This was 2005, or sorry, not 515, 2015. So that's eight years ago. The pattern is eight years old. It's allowed that Base cam code base to be in such fit condition that I open it up all the time now and I marvel, like, Jeez, it's not just even an eight year old code base, this is a ten year old code base. Because 15 was when we released it. We actually started working on it in 13. So. A bunch of these ideas are quite old, yet this pattern does not seem like it's gotten the purchase that it warrants. In other organizations. There are people using delegate types, but not nearly as many as I think they should. I think delegated types is one of those patterns that perhaps one out of three applications should probably be basing their main architecture around delegated at the types. So that's what's motivating me. I want to make an episode on that. And then there's a million other things. In the five years since you said I ended up with seven episodes, I'm sure there's going to be another seven episodes we can extract. Because what I think really resonated with that series was the fact that I showed real code. This wasn't pseudocode. This was code as it looks as it works today in I guess we didn't even touch hey, in Basecamp, the code is still running. Basecamp is still bringing in this huge multimillion dollar business is just flowing through the code that you see. And this is one of the things that, unfortunately is a bit of a rarity. Normally when people show code, they're not showing code from inside major applications. There's this sense of, are we allowed to do it? Should we do it? Is it secret sauce? Whatever it is. Getting an insight into the real code that runs a real application I think is just, for me, more interesting. I wish there was more content like that. I wish there were more large applications where you could really dive in and see what it is. Some of it, I think, is because some of the feedback I got on the Writing Well series was they didn't almost believe that's what the code looked like. That they thought, you know what? This is a stylized version of the code. That the actual code is full of the normal gunk that ends up in a lot of code bases. The normal entropy that affects a lot of code bases where you go, yeah, maybe that's one of the reasons why people don't show their code so much. They don't really like the idea that someone should come into their unkept house or something. To me, this is one of the reasons to do it right. As a motivating factor. That our code base. Our code bases at 37 signals. I take immense proud that they should look like stylized code. They should look like pseudocode. They should be so neat and pure. Not that they can 100% of the time, but like 90% of the time, every code base is going to have 10%. That's a little bit of a dark corner. Some code bases have 90% that's a dark corner and only 10% that's lit. I like the ratio the other way around, but yeah, foundation or series is absolutely coming back. I just need to get going on it. The funny thing was with unwriting, I think I did the whole season in not that long. Maybe a month and a half or two months or something. Once you get going with it. I find the same thing with writing. So I write a lot on my hey World blog, and sometimes I'll get into a streak, and I'll literally write every day for three weeks or four weeks. And then right now, for example, I haven't written anything for, I think, two weeks or something. So you've fall in and out of these streaks and sometimes there are things pulling on your attention. Absolutely. I'm coming back to it, and when I come back to it, I'll find, like, a permanent place for it to live. This was also the thing. I'm not a YouTuber, so I didn't really have a place for this to live. And then we moved it over to this getting real. And now we have a more active channel on 37 Signals. Maybe it'll go there. Probably will go there. Actually. If you go to Youtube.com, 37 Signals, you'll see that I've reposted those original episodes there. And we have all the other content where Jason and I talk on the rework podcast and the other things. So probably going to pour it in there so that's something people are interested in. Subscribe to that YouTube channel and it'll show up. Hopefully this year. I hate making promises. I'll say hopefully this year. And it'll be like three years. No, hopefully this year.

Emmanuel [00:31:34]:

Okay. I'm looking forward to its comeback. And since we started talking about delegated types, this pattern that you use, I understand you use this pattern inside of only Base Camp Three. Do you use it in Hay or.

David [00:31:50]:

In some other product also in Hay, yes, absolutely. So everything new we do uses it. It was instigated in the base cam three code base, which then morphed into base cam four. So its lineage goes back all the way to, I think, 2013. I think I added the pattern. And the funny thing is, the actual technical elements of the pattern is quite small. It really is an architectural pattern in it's. How you structure your application. There are some technical elements to it, and those things I put into Rails. But, yeah, basically anything material we've gone forward with has that pattern in there because it just makes so many things so much simpler. Anything where you have multiple pieces of we call them Records or Not Records. Recordings is how we named the pattern inside of Basecamp and also in parts of Hay, where you want similar functionality. Take the basecamp example. You have a to do list, you have a message, you have whatever, you have a file that's uploaded. All of them need comments. Are you going to build a comment system for each of them? Are you going to build a comment system for one of them? The delegated type system allows you to build a comment system for the Base type recordings. And then everything gets it for free. Anything that's a recording will now be able to be, as we call it, commendable. We usually phrase the pat or the concerns that we tie to the base delegated type in these terms, like it's a commendable. That means it can be commented on. It means all the structure the controllers deal with. It's essentially a type of generics where like Ruby as general doesn't need generics, it's all duct typed. But if you're used to a strongly typed language, the idea that you need to do something special to build generic code that can take any kind of object in kind of resonates. I'm thinking of this because I've recently been diving into Swift and Swift UI on the Apple side and it has just a very rich system for declaring generics, which on the one hand make me ever so thankful that I work in Ruby. That's just not even a concern we have to think about in daily Ruby. But this delegated type thing, because there's this interaction with the database that's a lot of what's driving it is the fact that if you want performant queries that can be paginated across multiple types, you actually can't do that unless you do something like this. You need a single table to aggregate your cursor information. So if you have a table that's just messages and you have another table that's just to do items and you want to thread all of that into a single paginated list, it's very difficult to do and it's not very performant. So a bunch of these reasons I'll go into all of that I'm trying to think, perhaps part of the reason why I haven't done it yet is like, how can I compress the delegated type discussion to 15 minutes? Because I tried to keep these short that they're not like two hour episodes, but I think it'd be much easier actually to make a two hour episode on delegated type than to make a 15 minutes one. But anyway, long story short, definitely coming back to it, definitely will post to it. Probably going to be on the 37 singles YouTube channel.

Emmanuel [00:34:46]:

Sounds awesome. And when you were talking, I heard you made mention of recordings and when you mentioned recordings, I was expecting that naturally you would segue into buckets. How do those ideas work together?

David [00:35:03]:

Yes, they directly tied together. In basecamp we have two base delegated types recordings and buckets. Buckets in basecamp are for anything that content can belong to as sort of its main ownership structure. And in basecamp it's things like we call them pings, like our DM sessions, that's a bucket, a project, that's a bucket. These things are both types of buckets. Even templates for making new projects is a kind of bucket that allows us to go, okay, a chat, for example, a chat system. So we have chat in base camp, can belong to any bucket. Now, that means the DMs use the same chat system as well, not templates, but as projects. Just even as soon as you have two, right? We don't have to build it separately because the ownership structure is generic. And then recordings is the delegated type we use for all forms of content that goes into these buckets. That is, your messages, your to do items, and even it's nested. So in To Dos is a good example because it's three way nested. You have a to do set that's like the whole tool. Then you have a To Do list, then you have a to do item. Each individually are Recordings, and that's a delegated type and it's nested such that the relationship between the three is also generic, which means that you can even go to do set, to do list, to do item, comment, and to comment, you can even go attachment. And that entire list is generic. You could have swapped things around if we made affordances to do, you could have attached a comment straight to a to do set. Or actually, as we do with to do lists, you can have comments on to do lists, that's the whole list. But you can also have comments on to do items. And that is all flowing through a generic system that requires no specialization of the domain model to make that possible. That was perhaps the main annoyance we had with the basecamp two code base, that it didn't have this generic system, it didn't have delegated types. So we ended up whenever we wanted to add a new type, let's say we didn't have to do list and we wanted to add that. Now there's a whole common system that manually has to be tied into. There was not a harness we could plug into. And this is why that delegated types pattern gives you so much mileage and why we've been able to remain happy with the basecamp code base for so long. Because, for example, we introduced a major new feature, was it earlier this year, called Card Table, which is our spin on kanpan. It's cards and you can move them to different columns and so on. It was all built on top of delegated types. The initial version of that feature was built by one programmer in six weeks. That feature is essentially a product. It's a substantial product. It's essentially a small trello in a box or a small Kanban product in a box. And that could be done within basecamp getting all these features. For example, the fact that you can comment on the cards for free, the fact that you can move these things, that you can move these cards to another project for free. Everything comes from the delegated type system. So it's one of those weird inverse things where the system actually gets more capable and more flexible the larger it gets, which is usually not the way it goes. Usually the way it goes, the larger the code base, the more convoluted it gets, the more complicated it gets to add new functionality, the more you really have to keep 1000 things in your head. At the same time. With this generic type pattern, you really don't. The more generic functionality, the more recordings functionality we add, the more value each new feature will get because it gets all that for free. As you can tell, I'm really very excited about this pattern. I think it is so important and it's rare for me to see a pattern where I still think about it ten years later. Normally things just become second nature and you stop appreciating them. For me, delegated types is like a nice nature view. If you have a nice nature view, it never gets old. You can look out the wind and you go, jeez, that's fucking beautiful. And I look at this delegated type set up in basecam and hey. I go, Damn it, that was a good one. I don't have a lot of sort of breakthroughs on the application side like that where I can just point them out and go, that was great.

Emmanuel [00:39:24]:

I feel like you could easily squeeze ten episodes from delegated ties just from this pattern for Onwriting Software World. So I'm really looking forward to the new season, which like you said, we should expect somewhere still in this year. We still have time, we still have a few months.

David [00:39:49]:

Yeah, let's make sure we don't jinx it here. But yeah, I really want to get back to it. And it's funny, I've had several conversations lately. You'd think, oh, it's been five years, do people still remember? Yeah, apparently they do. I still get a lot of emails about it, even internally. Jorge, who I've been working with on this new project where we were using delegated type, and he was ever so pleased with just how delegated types were making everything fall into place. We're like, we really need to get this out there. I think anyone listening to this conversation, you can check out the original pull request, which is probably still the best documentation. I forget whether how much we put into the rail stocks for this, but otherwise if you find delegated type rails PR, you'll find that original pull request from, I think, 2017, where I just spell out the basics of where it is, but it's not that well flushed out. So yeah, the video will do that.

Emmanuel [00:40:40]:

Okay, cool. Now, 37 signals moved away from the cloud. From reading some of your blog posts, I saw you got some machines that suggested that you were going to host your own stuff. I want to know, since you left the cloud, how do you manage your databases, like monitoring systems, backups redis and stuff like that? And what tools is it like you have tools that you've built in house that you use to manage all of these things. And if you have tools that you've built in house, do you intend like, putting some of them making some of them open source. So the ecosystem, the community can benefit from all of that.

David [00:41:29]:

Yeah, so it's a good question. I think most people, starting today, especially if they haven't been in the industry for a long time, know only cloud. Cloud is now the default, certainly for startups and certainly for anyone learning, which makes it seem like physical hardware is this exotic thing. The thing is, it's not exotic. That is what the cloud is. The cloud and running your own machines share so much of the same setup and processes and tooling that I think perhaps a lot of people would be surprised. So let's take some examples. For statistics, for example, we use something called Prometheus. For logging, we use something called Kibana, just those two examples. That's also what a lot of the cloud systems are using. A lot of these basic tools for logging or observability or whatever are built on open source packages. In fact, that's some of the grumblings, especially with the open source companies, that the hyperscalers just go in and then they essentially take their stuff and then they turn it into a service. The original company that's behind the open source stuff don't really see any financial benefit from that. The hyperscaler see a bunch of benefit. The nice thing about that is if you don't jump on the hyperscalers, if you don't jump on the cloud, the tools are there. We have not really had to build very much at all. The main thing that we've built is Kamal and we've already open sourced that and put it out there. And Kamal builds on top of Docker, for example. And the way our stuff is layered is we have the physical machine. Then we put something called KVM on top, which is a virtual machine management system where you can take these machines we have are so delicious, they have 192 threats in them. So we can carve them up right? It's rare that we need a whole machine for a single workload, so we often cut it up. And the way we cut it up is with KVM. And then we go two different paths for long term stable data. We actually treat these machines as pets. The dichotomy here goes. Pets or cattle? Cattle is just generic stuff you can tear down and build back up pets. You know what that machine is, it may be described, it may be described in TerraForm or something else. It may be described how you set it up in Chef, sorry, but it's not meant to be torn down and put back up. So that's what we do. We run the MySQL databases directly onto these KVM VMs and then we run all the application code, all the jobs, all this other ephemeral stuff that is like cattle, we run that through Kamal, through Docker. So it goes again, physical machine, VM, docker container, kamal putting things up and down, that whole stack from KVM to docker it's, if not exactly the same thing as the cloud people use in the same category. It's the same intellectual system. As I said, with metrics, we use Prometheus, with logging, we use Kibana as the interface for it. And then, for example, for Observability, we've used a bunch of different tools. For a little bit we used Datadog, which is a very nice commercial tools that just happens to be horrendously expensive. And as we looked at the builds for that, we went, you know what, this is not reasonable. Right now we're running on something called App Signal, which is actually a Rails app. They are coming to Railsworld as well. So really happy to support that. But perhaps ultimately we are building some of our we're not building putting together some of the pieces ourselves, like Prometheus and so forth, in a way where I'm not sure whether we'll ultimately end up needing something or not. But what is certainly the case is whenever I find anything that we do that I consider to be of potentially general interest, I can't wait to open source it. We open source everything at 37 Singles. Anything of merit is either already open sourced in the process of being open sourced, or there are plans for open sourcing it. I have nothing inside of our stack that I want to keep secret sauce. The only thing that we keep secret sauce, if you will, is our end user applications. But I consider everything else below that to be much better as open source. It's much more fun to work that way. It's enriching for the rest of the ecosystem. We've gained so much of it, as I just talked about, like that whole stack from Cabana to Prometheus to MySQL to KBM, these are all open source tools. We could not run our business without all of this open source technology. So giving back to the commons in that regard feels like actually it feels like a moral obligation. It's also just fun. It feels like it's the way to be in contact with the ecosystem. Aaron Nicholas, our director of operations, just recently put out a post on Dev 37 Singles.com, which is our Dev blog, describing how the infrastructure of the two data centers we use are set up. And there's more details in that. And we've also described on that blog, I think it was Farah who described how we had set some of these other so we're trying to not just open source the tools, but also open source, like the knowledge, and to some extent even open source the courage. I've talked to quite a few folks who have these towering cloud builds, who know something is not right, who know it's not good that they're spending millions and millions on these cloud setups, that it could be done cheaper, but haven't really felt comfortable because there hasn't been a lot of role modeling, there hasn't been a lot of clear direction. There hasn't been a lot of case studies showing what life after the cloud looks like. And this is one of the reasons why I've been so loud on this topic, because I think that's a really poor reason to be in the cloud. Like fear of what out of the cloud looks like. That's a terrible reason. There are good reasons and people who do solid sober analysis of it can come up with math that works. I think a lot of people, when they do that sober analysis will come up with math that does not work and will have an interest in getting out of the cloud. But let's be fair, there are reasons to still being in the cloud. And when I say we've done a complete cloud exit, I'm talking about all of the running applications, all the databases, all the app services on. We actually still have one component of our system, if you will, in the cloud, and that's s three file hosting. We're still looking to get out of that too, but we haven't yet. And I don't know if we're going to need some tools when we do that. We actually did build some tooling back, I don't know, what was it five years ago when we moved from Google's Cloud to Amazon for migrating masses? Amount of data from the file storage system. So that's an example of something do you know, what if we come up with something novel that there isn't already a good solution for, or that solution is just not to our liking. This is one of the things, for example, we got with Kamal was like, oh, there's this thing called Doku, there's this nomad, there are a bunch of tools. Yeah, sure. There's also a bunch of frameworks, there's also a bunch of programming languages. That doesn't stop me from exploring what feels like the right thing for us, what feels nice in the hand. I'm so focused on Ergonomics that I will often look at a piece of tooling, framework, library software and go, do you know what? I like what it does. I don't like how it feels, I don't like the grip. Like it has the wrong grip. So to me that's enough justification and motivation for me to start working on something. It's not even just about the outcomes, it's also about the Ergonomics and the grip.

Emmanuel [00:48:46]:

Do we have a timeline for the release of Rails 7.1?

David [00:48:52]:

Yes, and the timeline is very soon. Essentially seven one has been needlessly overdue. And the reason I say needlessly overdue is because seven one does not actually have any big blockbuster, major architectural earthquake in it that required a lot of time to get right. I think the last time I looked at it, it has something like 5000 commits. There are literally 5000 commits that have been accumulating over the past two years since the release of 71. But they're all small. There's some one that are very nice like we just talked about Camal, rails 71 will have docker file defaults that work really well with Kamal such that you can basically do Rails new and 2 seconds later you're deploying that with Kamal because the docker file is set up. Everything just works really nice. I really appreciate that. That was something I worked on for 71. Then we have this new API for normalizing attribute setting in active record. That's really nice. We have a bunch of things in there that are really nice, but they're not like at the level of what we had in 71. We're like, we're totally changing how the default works with the front end. We're bringing hot wire in. It doesn't have that, which to me means seven one could have been 717273 and it could have happened every six months. And I think that's something for us in Core to think about getting a little bit more of a cadence for the minor releases because I think not. What I think what is going to happen now is we're going to push out 71 very shortly. It's already the machines, the wheels are turning for that release to happen. I think the beta is going to drop basically any second. Definitely want it final out before Rails world and then we're going to jump into Rails eight. Like Rails Eight is going to be the next thing and I think it would just have been a little nicer. I think it's even written down on the release cadence that we try to release a minor release every six months and then a major release every two years and we're now at the two year mark, yet we just have essentially three minor releases packed up into one. A bit of organizational work I think for us there to just improve on that. But it also does mean that 71 is just really nice and it's going to be super duper easy to upgrade to because all of the changes are very incremental and a lot of it is just like polish, fixing little things. And that's the other thing. You look at the 5000 commits, I even go, that's a crazy number. How can there be so much this is what I also always astounds me about the newsletter, right, that every week you could put out a newsletter that sometimes talk about like 25 people have commits in a week. Like, how is there that much going on? And then you look through each single thing and you go, oh, that's nice. Oh, that's nice. Oh that's nice. That's the spoils of having a large engaged ecosystem. You just have so many thousands and thousands of programmers and companies that all are hitting like these little minute bits and edges of the framework that could be filed ever more slightly such that the entire experience just gets nicer and nicer.

Emmanuel [00:51:50]:

We've spoken about the release of Rails 7.1 and people are already trying to speculate what will be included into Rails Eight or what will ship with Rails Eight. And one of the things that keeps coming up from my tracking of conversations online is a full fledged authentication micro framework, if you will. Because in Rails right now, if you want to roll out your own authentication system, you can just do it. If you have a secure password, you can just write something that works. But if you look at a tool like Divides is like a whole engine, right? You have all your generators and it does a lot of heavy lifting for us. I checked some of the frameworks in other languages, and I realized they have systems like sophisticated systems that take care of authentication. In Rails, we do not have that. So is there a plan for Rails to build something like this for the community?

David [00:52:58]:

Yes and no. So first I'll say it's great that people come up with things like device and people are getting value out of it. To me, it's not the right level of abstraction. I think device does too much at too high of a level that mandates too many things, and then it gets into the trouble that high level components always get into is that if you try to do a lot at a high level where people might reasonably have opinions about how the flow should be or how it should look, you need to add in all these configuration points. And once you heavily start configuring a high level component in terms of looks and feels and flows, to me it quickly ends up being more work than just writing it from scratch. Now, some of that is that some of the core elements of authentication, especially modern authentication, OAuth or pass keys or any of these other things, there are elements in that we could do a significantly better job at encapsulating, such that those underlying things like has secure password, right? If we can have a handful more of underlying encapsulations of things for modern authentication, and then on top of that, do a slim but instructive generative framework that is not like device, where a lot of it is in the box and then some of it generates. But you have these court cases, let's say has secure password, the thing for authentication, and then you have a generator that just shows you how do these pieces fit together? It's not meant to be a final solution. In fact, one of the things that Rails for so long got slack for was that Scaffold was ugly. But that was a choice. Scaffold was ugly for a purpose because it was never meant to dilute anyone into thinking that you could generate an application and you could just run that. It was meant to be like, okay, this is just showing you the structure, the layout. You actually do have to change this such that it becomes your application. And I think doing something similar around authentication could make sense. I've talked to Rafael Franca who's been interested in this topic, and he's done some work on this. I hope we can now, not the whole, but a large portion of the Rails core team will meet up together at Railsworld. And these are some of the topics that we can discuss here. I recognize that there is a demand. I recognize that this is something people want. I don't agree with the level of abstraction in something like device, but I think we can get to essentially something that most people would find as good enough or better. Because the other thing with Rails I am so keen on is I want Rails to have a really flat learning curve, but a really long learning curve. I want you to become better as you use Rails. I want Rails to make it easy for you to get in the door, but then constantly teach you stuff right where you actually arrive at a place where authentication is not scary. I think this is one of the reasons why device and other tools have such an appeal that there's a large number of developers who look at authentication and go, oh, I really don't want to get this wrong. If I get it wrong really here, it's really bad because then someone could come in and they could see other people's data. Totally recognize that. What I would like is essentially the onboarding Ram to be an academy. You come in, we'll give you a base structure, but then we'll teach you this is how this works this way, this is how this works that way, and then you understand it in the end. Because I sometimes fear a little bit that people end up using something like device and they don't fully understand how it works or what the internals are. I'm not so keen on that.

Emmanuel [00:56:44]:

The third bit of hotwire is Strata. Now, I started tracking Strata from 2021, and then I went to the web page Hotwire Dev, and then anytime I go to that page, I just scroll down. There is a small text that tells you when Strata will be releasing. Every year that text changes. So now we are in 2023 and I want to ask what's holding the release of Strata back?

David [00:57:18]:

First of all, it's really funny because if you look at all the hot wire, turbo and stimulus are 95% of the value. But we ended up essentially like creating this unobtainable good, which made it so much more interesting for people to be curious about because it wasn't released. Strata is the final cherry on top that makes it easier for you to create a bridge between the HTML application you're serving from your server and the native elements that you have in your turbo native app such that you can have HTML elements that essentially instruct the native app to create native menus. That's often how we use it. What happened was we had some restructuring and then we got into other things and then it just was one of those things where, oh, yeah, we really do need to wrap it up, but it just didn't happen. Now it is happening and the reason I know it's happening is because Jay, who is the head of our mobile team and one of the key guys behind not just Strata, but all the native story around Hotwire is presenting Strata at Railsworld. So this is sort of like, all right, we got to get done with it. He made a wonderful internal presentation at the last 30 semicolons meetup, just going, this is Strata, this is how it works. And I thought, gee, we are done and we've been done for a while. This is things that often happen with open source, right? You end up you're 90% done and you're just like, nah, I really need the last 5% or 10% before I'm going to release it. We probably should just have released the 90% done like a year or two ago, but now it is finally coming and hopefully we will not need to increment the year announcement for that. But I think we run the risk of some people have being slightly disappointed because it's been so long. There's such an anticipation build up. Strata is very nice, we use it all the time. I think it does add something extra to it. You don't need it at all if you're building with Turbo native, you can already do a fair bit of this by hand. This just makes some of it slightly nicer to do. And second, you just don't need a lot of it. But, hey, let's complete the trilogy. Let's get the Hotwire all wrapped up in that regard. But I think actually the bigger change to Hotwire is something else we're going to be I think I'm going to be talking about at Railsworld. It's turbo eight. So there's some major new components to not components, maybe you'd call it components. Some major new aspects of Turbo that are coming that I'm really keen to, that feels like it warrants a new version of Turbo that's really going to do some nice stuff. We've been working on a new product internally and that's always I love that because every single time we work on a new product, whether it's Hay or whether it's base camp, we just extract so much new generic code from it, so much new open source stuff. And Turbo Eight, a lot of the things that's going to go into that is extractions from the work we've been doing on a new product.

Emmanuel [01:00:10]:

How do you envision the next version of Rails to look like? I'm talking about rails. Eight. What do you think it would look like? What should we expect?

David [01:00:19]:

So I could talk about some of the things we've already announced. Propshaft, for example. Propshaft is the new asset pipeline library that I'm keen to replace Sprockets with. Sprockets was ahead of its time when it originally, I think we originally released it in what, 2007 or something like that. But that was an era of Http one where you had to do a lot of munging of bundling things into assets. We had multiple asset hosts, I remember, that needed to go part with it because browsers at that time only open two connections per thread or whatever. It was something like it could only fetch four things at the same time. Now we live in a world of HTP Two. We talked about this a little bit with the discussion about these fundamental improvements that actually allow you to simplify things, which are the ones that make it really exciting to me. Http Two, ironically enough, is not that simple to implement. This is one of the reasons why Puma, our beloved web server for Rails does not support HTP Two because it's actually complicated to implement. But what happens after the implementation is vast. Simplification hey today does not use a JavaScript bundler. It runs entirely off import map. It has, I think, 90 JavaScript files that can be fetched. It fetches a bunch of them at the same time and it can do so over HTP Two in the same time, or less than what you would do if you bundled adults. Which means that for hey, we don't have a JavaScript process, we don't have a process that needs to compile the JavaScript. We're writing the JavaScript that runs in the browser directly. That is such a massive simplification on the toolchain that just has me super excited. So Propshep takes full advantage of that when we no longer need all this essentially pipelining and transformation of the files, that you can either outsource that if you still do it, and lots of applications do. If you build your application with React or something else, you're going to need a compiler. You can use Es Build, which is great compiler, if you're going to do that, use something like Es Build and then Propshaft just takes that as the final input file. It does not itself need to be able to bundle. And if you look up, and this is not for the faint of heart, but open the Sprockets gem bundle, open Sprockets. It's a bit of, I don't want to say a horror show, that's too harsh. It's a grab bag of a lot of experiments over a very long time, together with a bunch of solutions made for a different era. Propshaft is a clean sheet of paper. What is the simplest we can do to have an asset pipeline that has the same sort of generic load path, for example, which is my favorite feature of it, that you can reference your files for wherever they are, whether they're in gems or whatnot, without all the other stuff, and you get up with something much simpler. That's one example of something that gets quite a big change and I think there are probably some dependencies on Sprockets in certain ways for existing applications that will be a little hard to untangle. So we need to continue to support that, connecting to our conversation about not just upending everything, but for new applications. New Rails Eight applications should not be written to depend on Sprockets. So that's an example of something where the technology is essentially already there. It needs to be refined a bit more, but then it needs to become the default. That's the thing that we had this discussion the other day in Rails core, where when we come up with things that are better, I believe Props chef is something better for today asset pipeline. The Sparket we need to have the commitment to make it the default. If we just keep adding things on that, oh, yeah, if you know about this thing that you can turn on, then you'll get some benefit. No, that's bullshit. That's a cop out. Rails is here to present to you the best omakaza menu possible. The chef looked at all the dishes that could be put out, and Chef us, as a whole ecosystem really working on the framework, went, you know what? This is the best menu we can make. Not, hey, here's a good menu, but if you know the off menu items, you can get the really good stuff. No, that's not how we're going to roll. We're going to do it with the menu, is the best we can put together. So propshift is one example. There's also, for example, the MySQL adapter that GitHub and Fi both use called Trilogy, which is an advancement. We should get to the point where we're confident enough in these solutions that we make them the new defaults. And then there's a whole host of other interesting, cool stuff that I'm going to talk about at Railsworld that hasn't really been announced yet that I also have my eye on putting into Rails Eight as default. Some of this stuff is spilling out of new product development. Some of it is just spilling out of new hardware development. Actually, one of the other things that's really interesting to me is what's been happening with the hardware, and especially what's been happening with SSD drives. SSD drives to me, are fascinating because the advance that we've gone through just over the last five years, we've jumped so far ahead in speed of how fast these D drives are today that they're rivaling uses you would normally dedicate to Ram. And these are the kinds of tectonic shifts where suddenly the software actually can be written differently. You can have fewer dependencies if you go, oh, I no longer need Ram for this piece, I could use an SSD drive. And then you can let your mind run free of all the different things we use Ram for today that you might be able to use SSD for tomorrow. And the reason to do that is A, of course SSDs are cheaper, but B, because you get so much more of it. So suddenly, when you have multiple orders of magnitude of more space available, rather than Ram, you can do novel, interesting things that really, in my opinion, changes how the application is set up and also ends up simplifying the whole things. What do you need to get going with a Rails application? What is the absolute minimum? To me, the absolute minimum is you need a database, but beyond that, maybe you don't need so much more. Now, these are some of the questions we're exploring. I'll be talking a lot more about that at Rails World, and I'll be showing off a couple of new frameworks, actually. Is it framework? Is it libraries that fit with this vision? And I have it in mind for Rails Eight. So in many ways, I'm like Rails Eight is going to be where a lot of things come together at the same time. Some of the things have been cooking for years. I think I started propshaft year and a half ago or something like that. It's been marinating. We've been using it on Hay. Some people have been using it, but Rails Age is when we take all the good stuff that been cooking and go, okay, now that's it. That's the new default.

Emmanuel [01:06:45]:

Right after this whole conversation with you, I'm even more eager to attend to be at Realsworld. I'll be coming to Reals World, and of course, I'll be listening to your talk and getting some insights about what you're doing around Open Source, and especially what's coming with Rails Eight.

David [01:07:09]:

I am so looking forward to it. I cannot tell you. Just part of this is just the pandemic was such a weird time and we couldn't do the same things and so on. And then part of it was the weirdness that was going on around the other Rails conference, and part of it is just there's so much stuff we've been working on so many different things. I had a new project I started just a few days ago on another exciting things that's about The View. We're just going there's so many things I want to share. Like some years I've done a keyword keynote at a rest conference. There's one thing I want to share or one thing I want to talk about here. I'm like, how am I going to fit all this stuff in? There's so many things. So I think it's going to be a really special time. But I also do want to say, we only had those 650 tickets, and there are a lot of people who did not get a ticket. All the sessions are going to be recorded, and we're going to try to get them out in a relatively timely manner such that even if you don't make it to the conference and be part of the magic that is in person, you're not going to miss out on this stuff. And then, of course, also that the next Rails world is just going to be a lot larger and going to accommodate a bunch more people. I felt a little bit like it's this weird mixed emotion, right? You're like, on the one hand, you're really happy that there's all these people who are interested in coming to the conference. On the other hand, it is a little shitty that there's that many people who are like, I would have loved to be there, but I can't be. So we're going to try to make the best of this one with the recordings and getting them out early and then making the next Rails world be large enough to accommodate most of the people who want to come.

Emmanuel [01:08:35]:

Sure. I'm looking forward to it, and I hope to see you at railsold. Thank you for coming on the show, David.

David [01:08:42]:

Absolutely. Thanks again for having me. And thanks for all your work in the ecosystem. It's really great to see.

Emmanuel [01:08:46]:

It's a pleasure. Thank you.