Kaizen! NOT a pipe dream

Welcome to Changelog and Friends, a weekly talk show about pyramidical schemes. Thanks to our partners at Fly .io. Launch your app close to your users. Fly makes it easy. Learn how at Fly .io. Okay, let's Kaizen. Okay, friends, it's time to monitor your crons. Simple monitoring for every application. That is what my friends over at Chronitor does for you. Performance insights and uptime monitoring for cron jobs, websites, APIs, status pages, heartbeats, analytics checks, and so much more. And you can start for free today. Chronitor .io. Check them out. Join 50 ,000 developers worldwide from Square, Cisco, Johnson & Johnson, Monday .com, Reddit, Monzo, and so many more. And guess what? I monitor my cron jobs with Chronitor and you should too. And here's how easy it is to install and use Chronitor to start monitoring your crons. They have a Linux package, a Mac OS package, a Windows package that you can install. And the first thing you do is you run Chronitor discover when you have this installed. It discovers all of your crons. And from there, your crons will be monitored inside of Chronitor's dashboard. You have a jobs tab. You can easily see execution time, all the events, the latest activity, the health status, the success range, all the details when it should run. Everything is captured in this dashboard and it's so easy to use. Okay. Check them out at Chronitor .io. Once again, Chronitor .io. We are kaizening once again, kaizen15 and Gerhard, you will be pleasantly surprised. This is Friends 50. This will be our 50th episode. Wow, look at that. No way. Changed all good friends. I know you like round numbers and milestones. Yeah. So you're going to love this. No random integer here. Nice round 50. So here we are. Kaizen15, Friends 50, Adam's here, Gerhard's here, Gerhard's here. So good to be back. I was really looking forward to this one. We have a couple of things in store and I'm not digging it up. You will be impressed.

All

right. The gauntlet has been thrown. You will see. Let's see if you impress us this time around. Maybe I'll impress you guys. I know you will. Okay. That's easy then. You've already impressed me, Gerhard. I've been paying attention to those reports for you. Have you impressed me? Thank you. So good to see Adam as well. I'm good. I'm glad to be here. Of course. You know, just love the ride. Love the ride. Cool. By the way, just a heads up. We will be talking about B -days towards the end. Okay. So heads up. Very short. Very short. But there will be a short B -day conversation. Oh, you have thoughts on B -days as well. Yes. I thought you were talking about birthdays. Like you shortened it to B -days. No, no, no. Oh, is that how you pronounce it? It's just how I pronounce it. B -days. I'm glad that you know what it means. Okay. So you listened to our Friends episode with Kelsey Hightower, I assume. Yes. I really enjoyed it. All right. So I'm ready to learn because I've never used one. I've never even seen one in the flesh. So let's save that to the end. Yep. Because we have more important stuff to talk about. Yeah. So. All right. Take us on a ride, Gerhard. We will start somewhere, which is, I think, I think it's related to Jared, I think. But maybe it's Adam as well. So as you point out, Jared, I do like round numbers. I do like dates. Pay attention to those things. Right. So one of you will know what happened on June 21st, two years ago. Something happened this day, two years ago, and it's related to ShipItShow. Was it your last episode? Episode 90? No. No, that was in January. You're stumping me. I don't know. It's related to ShipItShow in June. Was it the original ship of ShipIt? So anyone with a terminal can verify this. Oh, gosh. You can do whois ShipIt .Show. Oh, we acquired the domain, maybe. We created it. 21st of June, 2022. That's when ShipIt .Show. How do you know that? How do you know that? Just random.

I

was paying attention to things. You have like a list of dates that you put in your diary and you're like, June 21st is now important to me because ShipIt .Show. No, I just stumbled across it. I just stumbled across it. That's how it happened. But I thought it was very interesting that on this day, two years ago, ShipIt .Show became a thing. So the actual domain. So that was nice. That is nice. Cool. So Kaizen 15. Tell everybody. So we're all on the same page. For those who haven't listened to Kaizens 1 through 14, what it is that we're doing here with Kaizen, why we're doing it, and then we'll get into it. Okay. So Kaizen stands for continuous improvement. And that's an abbreviation that many are familiar with. But change for the better. I think that's what the translation is closest to. So the idea of Kaizen started three years ago. Almost three years ago, by the way. And we will get to that. Three years ago, I think it was summer. The first Kaizen ever. Kaizen 1. ShipIt .Show episode 10. ShipIt .Show 4 slash 10 and you'll see it. And it started with Fastly. It was summer. It's when the internet went down. When half the internet went down. That's what happened three years ago. So the idea behind Kaizens was to improve things about the changelog setup on a regular basis and then talk about it. So the pace was every 10 ShipIt episodes. And it just happened to be every two and a half months. And for the past three years, every two and a half months, that's what we have been doing. And it's been a lot of fun. A little dig into this extended version of this, the meaning of this. It says, as we know, Kaizen is a Japanese term. It means improvement, or as you mentioned Gerhard, change for the better. And it says in the context of business, particularly manufacturing management, it refers to a philosophy or practice that focuses on continuous improvement of processes, products, and services. And here's the part I like. It says the concept of Kaizen involves all employees from top to bottom, all management to the assembly line workers, and encourages a culture of sustained incremental improvements. I think that's a, it encapsulates a bit more because it involves everyone. It's not like you or Jared or just me, it's a collective. And it's this culture, which I think is interesting because like Kaizen has, you know, most of the pillars, Jared, of our business are built by you and I, right? Like you and I, Jared. And then here comes Gerhard with ShipIt and all the things he's done with us for the past, I don't even know how long, but pretty much forever. And he brings in this new pillar called Kaizen, right? And I think this is very much Gerhard born, but adopted by all. And I'm really thankful because Kaizen has become part of my own personal DNA as well. And I like that. That makes me so happy. I'm really glad that three years after we started, we just add another brick. You're right. It does include everyone. We've always done this, all three of us. We've never done it on like separately. So from the beginning, this has been the secret formula and there has been a lot of navel gazing. That's a fact, which is something that I generally am allergic to and I try to avoid. But actually, do you know what it means? Do you know what navel gazing means? Well, it's a stare at your own belly button. It's the contemplation of one's navel as an ace to meditation. So you're contemplating the basic principles of the cosmos and the human nature. Check Wikipedia. So onphaloskepsis, it's Greek. That's where it comes from. Navel gazing. Jared here in the editing room. You know, I thought onphaloskepsis sounded familiar when Gerhard said that, but I couldn't quite put my finger on it. Now that I've had more time to think about it, onphaloskepsis was our word for round three in the Pound Defined Game Show we played on episode 25. Maybe you recall it? Game Theory Dude? I'll link to that chapter from this chapter in case you want to jump over there and listen to it before returning to our navel gazing. Okay, back to the gazing. And there's lots of statues of Greek dudes, very muscular dudes, great looking, gazing at their navels. Yeah, similar to us. Similar to us. Exactly. With more hair. They have more hair. Yeah, well, they do have more hair. Yeah. So I think Kaizen is a better name. I think, yeah, I quite like that. Yes, I do as well. Let's put a new spin on navel gazing, though, for me, because it's generally been a frowned upon term. Well, it's something that you do for yourself by yourself. And so navel gazing, I think, in public is where it becomes frowned upon. You can search your own navel all you want, if it helps you with your thought process and your self judgment and all that kind of stuff, go for it. But navel gazing

is

a private activity. And when we do it in public on the airwaves, at a certain point, you're like, let's stop staring at our own navels. But in so far as it's continuously improving our navels. Back to mine and someone else's. That would be weird. I would have to agree that, yes, navel gazing outward is worse than inward. So at least we aren't going that far. But I do agree that Kaizen is a much better way of framing it so it feels OK. Here's maybe a better twist on it is if you're going to navel gaze, turn it into a product. Like this is a product. Kaizen is a product, right? We produce something as a result of navel gazing and we're doing that, but we're doing it in the manner and the culture of Kaizen, continuous improvement, improvement for change, change for the better. But at the same time, we've turned this sometimes habit or circumstance of just wanting to popularize the things you're doing and not be overly self -promotional. And we've always been a little guarded with being overly self -promotional. But I think that there's been so much value in all the Kaizens and all this navel gazing, Kaizen change for the better stuff that I think I now see a positive style and a positive light to what is typically determined as navel gazing. Yeah. Now I do think that we've been sharing and promoting a lot of the work that the community has been doing from the open source. We've been promoting projects. We've been helping some of our partners improve themselves, whether they wanted to or not. We had some of those as well. The idea is we've always been outward looking and we try to make everyone that integrates with us better in some shape or form. And that makes me really happy. Well, while we're navel gazing, navel gazing, we've gone up a level or down a level depending on which perspective you have. I want to talk about continuous improvement versus continuous change because while we bike shed and talk about the details, I think there is a culture of change for change's sake, which we could fall into and perhaps have. And sometimes you don't know what is improvement and what's actually steps in the wrong direction. I think we should ask ourselves as we move along, are we just continuously changing for change's sake or are we actually improving? And that's part of the iteration process. It's also part of the judgment, the retrospective. How is it going? Was this a change for the better? Similar distinction I make between productivity and effectiveness. I think that you can produce a bunch, but really what you want is to be effective in whatever you're doing. And sometimes you're just producing. And it's like, well, cars produce as well carbon dioxide or whatever, right? So not always the best thing. So instead of trying to be productive, we should try to be effective. And I think instead of trying to continuously change, we should make sure that we are continuously improving, which I readily admit you can't know that until you make the change and then you can judge it. But something maybe as a North Star, as we move forward is like, is this change actually for the better or just for the sake of trying something? All right, let's stop navel gazing, the navel gazing. Let's start looking to the standard navel gazing now. So I have a couple of items on my list and there's like three buckets. Okay. So what can you expect, right? You've just joined or maybe you skipped forward through the navel gazing part. Yeah, chapter break. So what can you expect in this episode? The first thing I would like to give kudos to some people in the open source community. They did some great work.

I

would like to share some Fly .io love. There's a lot of Fly .io love to go around. We'll get to that in a minute. And also I want to talk about turning pipe dreams into reality. And that's an important one. So rules for today. We'll share the background story, right? We have lots of stories to share between the three of us. We will share those stories. Okay. No peeing in pools. Remember the last one? No peeing in pools. Okay. And most important, you want to celebrate the wins. We had quite a few. Navel gazing is allowed by the way you can do it. It's okay. Right. And you can't see mine, so it's all good. That's right. So the first thing, the first person that I would like to congratulate is you, Jared. Me? Yes. Well, let me have it. Why? What I do? You made the first PR in nine months. I noticed that. I did. I did that kind of for you. I did that kind of for me. I was like, it's been a while. You know, I normally just push straight up on the master branch, but I thought this, this is a noteworthy change. I should open up PR and Gerhard is going to love this. I did. I loved it so much. So 510 pull requests, 510. If you go and open up GitHub, our GitHub, um, the changelog, changelog .com, uh, news redesign. Oh yes, baby. That was amazing. By the way, baby, I'm only using it, you know, as, um, an endearment. The fact that it took nine months has nothing to do with it. Okay. This is not your baby. It's a labor of love. It's a labor of love. It's passion commitment, but it's not a baby. So anyone with this thought, I want to discourage it. Okay. Okay. Good. Yes. So I would love us to talk a little bit about it and I would like to start anything you want to share any of the background stories, any of the things that you want to share about the news redesign.

Yeah,

absolutely. So background story is that we had a newsletter for many years called changelog weekly, which you would subscribe to on changelog .com slash weekly. We also have a nightly newsletter, which is still going, which is an automated scraper of the most starred repos on GitHub, which is increasingly becoming simply AI crypto and malware. So it's getting to be less useful than it used to be, but that one goes out weekly, went out weekly. That's why we named it weekly, right? Adam, we had a hard time coming up with a better name for that because, well, we already had nightly and weekly and,

and

it was, it was what it was. And then we started the changelog news podcast as a flavor of the changelog, which was quite a success, a hit. People liked it. We liked to do it. So we kept doing it and we decided to streamline the newsletter and the podcast, set them out at the exact same time. They were already complimentary. Let's just make them more officially complimentary. And so changelog weekly became changelog news, which is just both podcasts and a newsletter. People who are listening to this pretty much already know that the technical side of that was that the podcast became its own podcast in our system and had a podcast page, just like all the other ones, just like ship its page, just like JS parties page, et cetera. But it had this newsletter component that wasn't very well featured basically. So when you go to changelog .com slash news, you would find the changelog news podcast, and there'd be a subscribe button with newslettery things, but we weren't featuring the newsletter at all. And so this redesign was an effort to have a different page that lives on changelog .com slash news that serves both the podcast and the newsletter better in terms of people understanding what we are doing there, being able to quickly read the most recent issue, give it a better splash page because lots of people land on that page and we want them to know what it is. And it's more than just a podcast. So that's the backstory, a couple of shout outs, of course, Cody Peterson, who worked with me on the design and the front end implementation of the new splash page, shout out to me for coding it up and opening up an epic PR, which I don't normally do. And to a handful of folks who decided to send us kind words to use on the page. We have a lot of people who enjoy the podcast, enjoy the newsletter, and they tell us this privately via email and stuff. And so I reached back out to everybody who reads it and said, hey, if you would, you know, give us a quote, we'd like to put some of those on the homepage. And so shout outs to Mary, to Justin, to Chris, to Maros, and to Fraal, Fraal, Fraal, sorry about that, Fraal, whose quotes were awesome. And we got more than those. So thank you to everybody who sent one in. Those were the five that we selected to feature on the homepage. And that's pretty cool. I think being able to hear from and see some of the people who take value in the newsletter, I think is powerful when you're trying to decide, like two things you want to know is like, A, do people like this? And then B, what does it look like? Like show me a recent issue. And I think with this redesign that we've accomplished that. So that's that. Coded it up, rolled it out. It's there. It's ready. So I really love the emails. It's one of the few newsletters which I read. So whenever you send the newsletter, Jared, I really enjoy it. I have clicked on the view in browser button. And I noticed, I think until about 90, like issue 90, it had the previous design. That was Devin's Upwork side hustle expose. That was the last issue which had the new design. And then 91, it was the new one. So all you have to do is literally drop the email part and you'll see the previous design. So news forward slash 90, forward slash 89, so on and so forth. And the reason why I said 89 is because maybe you've done it by design. Maybe you knew what you were doing in this case. The previous issues have also improved. So when you ship the redesign, all the previous ones

look

amazing. Oh thank you. We did it on purpose. We did them all. You've done it on purpose. If you haven't seen that link in the email, click it and check it out. Otherwise, change .com forward slash news forward slash 90. So I have a question and I'll go first. Okay? Okay. Okay. It always gives us time to think. Exactly. What do you like most about the new redesign? About the news redesign? What do you like the most? I will go first and you'll understand why in a minute. So my favorite feature of the new redesign is the 27 more reasons to subscribe. Oh you like that part. I love that. In particular, reason 15. Okay, which says? Who else takes the time to list 27 reasons to subscribe? Right? That's right. I thought somebody in the world would get a laugh at that and I'm happy to hear that it was you. Oh man, that was so good. That was so good. It shows you read all 15 or all 27 because you got to 15. Yeah. Did you make it all the way through? I did. Okay. And I improved it. And I'd like to show you how. Okay. 28. Are there 28 reasons now? Well, let me share my screen. I will obviously narrate this and you'll understand why. Okay. Okay. So what I'm sharing right now is changelog .com forward slash news forward slash 99. Okay. So if you go in a browser, you can see this. 27 more reasons to subscribe. Love it. Okay. Reason 15. Amazing. So how would I improve it? I don't know. Oh, 29 more reasons to subscribe. Okay. 29 is important to me, right?

It's

only my birth date. It's a very important number. Only my birth date. Did you add two reasons or did you just change the text? Okay. No. What did you get? Scroll, scroll. Yes. He noticed it. So what I did, hang on, let me just make this a little bit bigger. What is different about this list? Well, it's got zeros in front of it. Or did it have zeros already? No, it did. Okay. My bad. Well, it, it goes in like, it's a pyramid scheme. It's done that in the newsletter before. Have you noticed? I know you did. That's why I paid attention to that. Sometimes. Okay. I love that. Yes. It gets longer and longer as you go down. So you've reordered them. I did. And I had to, so I'm going to submit a pull request and you let me know if you like it. Okay. I'll accept this. Cool. Okay. And for everyone else, there will be new pull requests. I don't know the number, but by the time this comes out, I'm sure we'll have a link. So funny story about this particular feature. This was almost entirely Cody's idea because I'm like, I want to put a, I want social proof, right? I want people's quotes on there. And then B we do a few things differently and they're all minor. Like it's like minor reasons, but I want to have somewhere a list of like the stuff that we do. Like we don't track your clicks, blah, blah, blah. And he's like, well, what if you just did like way too many of them and just made some up and he actually stubbed it out with 36 reasons. And I was just, I took it as a personal challenge to come up with 36 reasons why you should subscribe. And I'm like in the mid twenties, I'm like, Cody, this is too hard, dude. I can not come up with, he's like, I did not expect you to come up with 36 reasons. I just made up a number. And so I finally made it to 27 and and left it there. But I love that you've improved it. You've added to,

I

will go on record to say we are accepting pull requests on reasons to subscribe. So if you have more reasons, I would love to get that number as high as humanly possible. 99 99. Yeah. I mean, you have to subscribe if you read 99 reasons, don't you? Hit me. Excellent job here. I will. Thank you. Thank you. What's up friends. I'm here in the breaks with David Hsu, founder and CEO at Retool. If you didn't know, Retool is the fastest way to build internal software. So David, we're here to talk about Retool. I love Retool. You know that been a fan of yours for years, but I'm on the outside and you're clearly on the inside, right? You're on the inside, right? I think so. Yeah, I'd say so. Okay, cool. So given that you're on the inside and I'm not on the inside, who is using Retool and why are they using Retool? Yeah. So the primary reason someone uses Retool is typically they are a backend engineer who's looking to build some sort of internal tool and it involves the front end. And backend engineers typically don't care too much for the front end. They might not know React, Redux all that well. And they say, Hey, I just want a simple button, simple form on top of my database or API. Why is it so hard? And so that's kind of the core concept behind Retool is front end web development has gotten so difficult in the past five, 10, 20 years. It's so complicated today. Put together a simple form with a submit button, have that submit to an API. You have to worry, for example, about, Oh, you know, when you press the submit button, you got to bounce it, or maybe you got to disable it when it's, you know, isFetching is true. And then when it comes back, you got to enable the button to get, when there's an error, you got to display the error message. There's so much crap now with building a simple form like that. And Retool takes that all away. And so really, I think the core reason why someone would use Retool is they just don't want to build any more internal tools. I want to save some time. Yeah, clearly the front end has gotten complex. No doubt about that. I think even front enders would agree with that sentiment. And then you have backend folks that already have access to everything, API keys, production database, servers, whatever. But then to just stand up Retool, to me, seems like the next real easy button because you can just remove the entire front end layer complexity. You're not trying to take it away. You're just trying to augment it. You're trying to give developers a given interface. That's Retool. Build out your own admin, your own view to a Google sheet or to the production database, all inside Retool. Let Retool be the front end to the already existing backend. Is that about right? Yeah, that is exactly right. The way we think about it is we want to abstract away things that a developer should not need to focus on, such that the developer can focus on what is truly specific or unique to their business. And so the vision of what we want to build is something like an AWS actually, where I think AWS really fundamentally transformed the infrastructure layer. Back in the day, developers spent all their time thinking about how do I go rack servers? How do I go manage cooling, manage power supplies? How do I upgrade my database without it going down? How do I change out the hard drive while still being online? All these problems. And they're not problems anymore because nowadays when you want to upgrade your database, just go to RDS, press a few buttons. And so what AWS did to the infrastructure layer is what we want to do to the application layer specifically on the front end today. And for me, that's pretty exciting because as a developer myself, I'm not really honestly that interested, for example, in managing infrastructure in a nuts and bolts way. I would much rather be like, hey, I want an S3 bucket. Boom, there's an S3 bucket. I want a database. Boom, there's a database. And similarly on the front end or in the application layer, there is so much crap people have to do today when it comes to building a simple CRUD application. It's like you probably have to install 10, 15, maybe even 20 different libraries. You probably don't know what most libraries do. It's really complicated to load a simple form. You're probably downloading almost like a megabyte or two of JavaScript. It's so much crap to build a simple form. And so that's kind of the idea behind Retool is could it be a lot simpler? Could we just make it so much faster? Could you go from nothing to a form on top of your database or API in two minutes? We think so. Yeah, I think so too. So listeners, Retool is built for scale. It's built for enterprise. It's built for everyone. And Retool is built for developers. That's you. You can self -host it. You can run it in the cloud and custom SSO, audit log, SOC 2 Type 2, professional services. Starting with Retool is simple, fast, and of course it's free if you want to try it right now. So go to retool .com slash changelog. That's R -E -T -O -O -L dot com slash changelog. Now I want to show you a really cool feature. So I've used the previous improvement we shipped in the last Kaizen, which is I'm connecting to neon from my local environment. Look at this. So I've done this. I've created a branch. I think it was a few days ago. I can't remember. And obviously master has moved since. So if I'm going to close this, I'm going to go to localhost 4000. And if we go to the podcast, Securing GitHub, 2024 -06 -19. Right. Right. I'm sure there's a new one. Let's just go back to the main one. Let's see what it is. What's the last one? So polypane demonium. JS party episode 327. Cool. So neon, I have the console open. I'm going to click on my branch and I'm going to say reset from parent. This is me syncing the data. Yes. Reset. This is your dev branch. Yes. Okay. Done. That was fast. Two seconds. I come back so fast. I refresh polypane. Boom. Bam. That's cool. So that was it. All right. That made me very, very happy. Very happy. Like the whole thing. Really cool. So over to you. What do you like the most? I'm going to stop screen sharing. What do you like the most about the news redesign? Well, you kind of stole my gear and I was going to say the 27 reasons. It's okay. Dollar 29. That's good. That was definitely my personal favorite part because it's just kind of zany and something you don't see all the time. And probably that most people wouldn't even notice, but it's there. And so, yeah, I'll just, I'll pile on. I'll say the 29, the pyramidical structure of 29 reasons to subscribe is definitely my favorite part. Adam, yourself? I think it's just as simple as having a much better landing page after literally just so long, right? I mean, so long. I can't even tell you how many years to have a more, a better place to send somebody to subscribe that, that showcases the content and the reasons and the ability and the social proof all in one place. Like this divided design was, was like, let's, I know our newsletter, like when we first talked about it early on, like before it got into like code or dev or like really like some fleshed out design, we were talking through like, okay, the newsletter could be on the right and the left side can be static and you can easy scroll on the right. And it matches the brain because the left side can be dark and the right side can be the content. And you know, it's obviously massaged and more since then, but the basic idea was really good. But then having a place now to just call home for changelog news, which is changelog .com slash news. I really wish we had dot news, but whatever, we won't get upset about that. That's holding out. I mean, Gerhard knows the exact date that we bought ship a show, right? Like when we get changelog .news and I can stop saying .com slash news. I mean, that's going to be a huge win and someone out there, but who holds that domain and needs negotiating power better not listen to this. Cause when I talk to them, I'm totally going to play it cool. Like, Hey, you know, you care about this domain. I mean, just squatted, happy to pay some money for it. Just don't want to get raked over the coals for it, but man, we got to have changelog .news. It's just so much cooler. Yeah. And really too, like I think my other favorite thing about this is that it didn't, the existing newsletter design didn't have to change really at all, if any, to fit into this new design. So the original email design got pulled into this. And so I think that's kind of nice that we can literally incrementally improve Kaizen, this newsletter to be beyond newsletter, a decent design and good design and great content to a full on landing page that, that doesn't have to change a lot. It just sort of added to, it was additive versus total morph. So I like how literally how iterative we got to this point to have this kind of page. And one more note on the newsletter redesign. So for those who haven't seen it as Adam described on the left hand side, it's dark and is really representing what you're looking at and has the reasons to subscribe the buttons and stuff. And on the right hand side, it's the most recent issue. So you're literally reading what it looks like. And that's in light mode that the right hand side has a white background. Now in dark mode, they're both kind of dark and there's a border in between. But the idea behind this kind of the meta game is really it's the podcast slash newsletter is a hybrid. It's two things in one. It's the only podcast that is a newsletter. And it's only a newsletter that's also a podcast that we know of in this space. And so you kind of have this Two -Face thing going on where it's like, there's a duality to the content and there's a duality to the design, which I think is kind of cool. Probably that gets lost on most people. But for those of us who put it together, we just thought that was kind of neat. Now, I don't want to directly reference Two -Face because I realized he's a villain and it's probably not the best association, but you know, it's got that duality thing going on, which is pretty cool. It took me a while to realize that there is a button in the top right corner you can press play. That's the one thing that we probably should continue to fix and make better is like you want to be able to read it and you also want to be able to listen to it. And yes, there's a play button in the right hand corner. And as you scroll the newsletter, like that's sticky, it's not going to scroll with it. So it's always right there. But I'm guessing and I don't look at stats very often, but I'm guessing less people are listening to it on the web than used to be because it used to be our standard episode player, right? And now it's kind of a unique thing. You also can't like skip chapters and stuff. I think when I'm wanting to scan an episode and see if I want to subscribe, I kind of want to click through it and maybe like scrub it. And none of those tools are there because we kept it very stark, but definitely ways we could make it better and make it more obvious that yes, you can also listen to this right now while you're staring at it. And you almost want like a player of sorts, but then that's too much. Like does it really require that because like the listenership isn't there on the web to like put that dev behind it. I think design -wise it could stand out a little bit more like the play button could be more play button -y besides like literally a play button. I don't know, it's great design. It's just there could be some tweaks and turns to let it stand out a little bit. Some sort of affordance that draws attention to that play button. Maybe it like

has

some sort of a sheen to it or like something that just draws your eye over there and makes it seem maybe even the word play under it. So you can just say, oh, I can play this because we all know what a play button looks like, but they kind of blend into the background when we're reading. So

yeah,

we could definitely make it better. I really like how we are improving Jared's pool. This is amazing. I'd like us to keep going. We are improving it for sure. I appreciate it. I appreciate it. I guess the question for you, Garrett, is you showed off neon there and you showed off how you can reset to, what was it, parent branch? Was it, is that what it? Yeah. Okay. So I have a branch and I was just basically synchronizing it with all the data that's in the parent branch. Well, why did you show that off? Because I was using it locally, right? And obviously the two diverge. So I have my own branch, literally my own branch from the database that I can always synchronize, basically catch up with master. Dev underscore Gerhard or something like that, right? Doesn't that give you like a default? It doesn't have my name yet, but it has a date. Okay. It doesn't? Okay. Gotcha. Yeah. So what happens if you make local changes? Maybe you go in there and delete some episodes while you're doing development. It's on my branch. It will not affect the production. Right. But then when you hit sync, it's not going to merge changes. It's going to just, it's one way back to where you were. It's it's one way. Yeah. That's what you want. Yeah, exactly. I'm still a little tentative of those things. Cause like I have, I guess anxiety is the word, you know, one time I played basketball early in the mornings and one time I got halfway to the gym and realized I didn't have my socks, which pretty much ruins it. Right. And it's a 20 minute drive. So like, I'm either coming home or missing that day. And ever since then I've had like, do you have your socks anxiety? And to the point where I put them in my bag, I put my bag next to me, I'll start to drive my car and I'll stop. I won't stop. But I'll like think to myself, do you have your socks? And I know intellectually that I have my socks because I literally, but I'll still just check. I'm like, well, I'm just going to check. Oh yeah, there they are. And I have that a little bit when you're like just having this mat, this production branch and then your dev branch and you're doing stuff and like, am I sure I'm not connected to the production branch? You know? Yeah. It's a little anxiety ridden for me still. And probably because I'm just not used to it. Or if I get bit by it one time, I'll probably never want to use it again, but the value is there. So it's interesting to me, but I'm still kind of just a little bit like, I don't want to accidentally screw something up. Yeah. Well, there are backups. The whole point is like, if, if we did make a mistake, is the system resilient enough that we can recover from it and how quickly can we recover from it? Sure. Right now, let's say we delete something in production. Well, do we have a backup we can go back to? Yes, we do. How much are we going to miss? Not that much. Yeah. I guess the things that make me nervous are like accidentally sending emails to people or deleting MP3s off of a CDN or like there's stuff that is recoverable, but

a

bunch of work and embarrassing and stuff. So that's just standard. I think all developers have these concerns in the back of their head as they're Yeah. For example, CDN, you only upload, you don't allow like the keys to, to like the keys that you use to upload are not able to delete. For example, you have a separate set of keys for this branch. You're just telling me what we should do, right? Well, yes, exactly. Very subtly, very gently. I'm taking notes. That's really smart. Yeah. That's interesting to let you have keys to unlock, but not keys to lock. That's kind of like the concept, right? Like I have a key in my hand. If the door is, you know, unlocked, I can lock it, but I can't unlock it with the same key. And actually we can't delete MP3s. We could overwrite them with other MP3s, but it is write only in that sense, not delete. So that was just an example of things I think about. The reason why I asked you about the, why you showed that off, because I think the last, either the last Kaizen or the Kaizen before, Jared, you shared apprehension of Neon in the dev branch, branches space, because we contemplated latency. We contemplated the cost. And there's a lot of things that I've learned since then. I had a great conversation literally yesterday with a fellow named Brian Clark, who is the VP of product at Neon. And so we were talking at length and this will come to an ad spot near you, of course, but we like to do really cool ad spots for our content. But I learned a lot about this, that the database spins up in 500 milliseconds or less. So literally half a second, that if you walk away from your machine, you're in development mode on your local branch, you know, doing development on a branch, that the database spins down to zero after five minutes of inactivity. So there's no long -term polling. So it spins down to zero. The cost is basically nothing because you're in dev mode, unless you're creating data, then only then would you pay more for space. So it's really just time on the CPU, the diffing there. And then obviously the whole thing that Gerhard just showed off, which is why I asked this question, was this reset to parent so that you can suck in more data so that you can actually have prod -like or literally prod data in dev mode with just the slight cost of a little bit of latency, because it's literally not local. So there's not going to be, it cannot compare to local. But then Brian did also divulge some potential future stuff that I'm going to mention here, because it's not an ad spot and it's cool. They're going to work on the ability to go offline with your database and still be neon -like. Like neon locally dev branch, all the fun things you want with neon local dev branches, but go offline, go on a plane, go on a train, whatever it might be. That's future coming. I'm kind of like future is spelling for them. So don't get too upset neon, please. But this is cool tech. They're working on it and they have a plan to like continuously improve this developer workflow with a database, which has not been there really at large ever. And it's on our favorite database Postgres. So that's a beautiful thing. Well, that leads me to what I asked Gerhard for last time. Didn't I ask you for something like that? Yes, you did. Fresh data, something about booty. No, no, no. Yes, I do recall something about that. So, yeah. OK. So, yes, you did. I have something else for you, though. OK, it's not ready. Is it called more booty or double booty? It's called pipe dream. It's called pipe dream. It's called pipe dream. Cool. Let's hear it. So we're not ready for that just yet. We still need to stay like in the news redesign camp for a little bit longer because I was going to share a couple of things that I think would make it better. OK. So first of all, it's obviously like that player. We talked about that a fair bit. The second thing, which I wish was there, and I don't know, you know, where you stand on this, but just a very faint background on the sponsored segments. Right now, they all like blur. And I think it would be very helpful to see what is sponsored, what isn't without basically just like by skimming, because it just puts me in the right mode and it feels like it's more honest that way. So sponsor sections, just like a fainter gray or faint or whatever, like it has to be tiny. Like it shouldn't be. No, it's not an ad because it's not an ad, but it's slightly different. Also, the shout outs, I think the shout out sections would be slightly different. It would make it easier to digest because now it's not like one long newsletter. It has like parts to it. I would quite like that. What do you mean by the shout out? So you're talking about when I give change log plus plus shout out? Quote of the week. Oh, quote of the week. Yeah. I think also like a different background color because those, I think those are like good. And for example, I've seen quotes. I wanted to go back to them and I didn't quite remember where they were. So I had to basically start reading to get to, oh, here's the quote that I was looking for. Right. So tiny things, tiny things. Yeah. I mean, I'm not against any of those things. Some of this is my desire to write the newsletter on my own which is basically in raw markdown without any sort of additional tooling. And so the only like special formatting that we do is on the sponsored posts. Like that's an H4, I think when we give a thanks to, you know, one password for sponsoring changelog news. And we just style that differently literally cause it's like just the only H4 or H5, I can't remember which one that I actually use and everything else is H2s and H3s and block quotes. And it's like literally just raw markdown which helps me actually author any timely and enjoyable fashion. And so there's no special, there's no special anything. So there's no way that like, we don't know semantically that a certain thing is sponsored except for that it has that little H5 or H4 under it. Now we could probably do some fancy footwork and detect that and like just based on the way I write it. So I could get more formal on certain things, but I don't do any like classes, any tagging, anything like the quarter of a week is literally me making an H3 that says quarter of the week and then a block quote. And then that's it. Like that's what the quarter of the week is. And so in our system, there's no fancy formatting because it's so free flowing and that allows me to be more, I think, creative and experimental with what I'm doing. Like quarter of the week is not always there, which is like, I think it's funny. Like there's not always a quarter of the week. There's not always a video of the week. So it's not like I'm saying I need a quote for this week and I plug it into the quarter of the week block. So it's more of a result of how I write versus an editorial decision. And we definitely used to have the sponsored section, I think was more called out than it is currently. And I think we could do some coding and just follow the same syntax that says, when you find a section that has this particular element in it, then change the style or something. So I'm not against it. It was just like, we wanted it to be as free flowing as possible so that I could continually put them out every week. Yeah. Your perspective though, Gerhard, I understand that too, but do you feel, this is important. Do you feel duped? What is your feeling whenever you feel like these things blend? Because it's not meant to be dubious by any means. It's just meant to blend a bit more so, like Gerhard said, like it's not something special and then adding, hey, thanks to One Pass for sponsoring Channel News. That was the last week's sponsor just reading that. And obviously in the audio it's called out, right? Like it's pretty clear in the audio, but it's less, it blends more so with other content in the newsletter. So I would like to have the option of quickly skipping over a section if I so choose. It's almost like, okay, this is different. I know what this is. I can skip it. I can come back to it if I want to, but this is something different from the news items. And then this is a sponsored news item. And this will talk about most likely the benefits of the tool or how it can help me or things like that. And I would like again, to have that option of skimming over it quicker. If I so choose. Now, sometimes in the mood of reading everything and that's okay, but other days I'm just skimming for something. I remember seeing something and I want to go back and I have to do quite a bit of reading to get there. The headings help, but it all like blends together. And also the quote of the week, I think they're good to shout out and seeing that like slightly different because it just puts me like in another mindset. This is something that some person said, and maybe I'm interested in like digging deeper for this quote. Maybe there's an episode and most likely is an episode. So it pulls me in that direction. And being honest about that, almost like interaction, it would, I would find it more pleasing. Maybe it's just a, it is just a personal preference honestly. Yeah, it's good feedback. No, I mean, I definitely think

that

there's times where you're reading a newsletter and there's times when you're scanning a newsletter. And I think that while it's not difficult to see the things for sponsoring Change .News with the, we've put the cash bag emoji. I mean, most of our actual sections and breaks is like horizontal rules and emoji, right? And so like the quote of the week always has the exact same emoji just to start it out. And so I try to be consistent with those things because I know they are visual cues for people. I think that we could probably make the sponsored posts slightly more prominent without having to like rework my entire, you know, publishing workflow. You know, maybe always putting the, like, for example, to read the headline, strong, unique passwords for you and your team. That was the one passion one from last week. Maybe move the money bag up to be the emoji on the thing versus the strong arm thing, which I totally think is contextually correct. Maybe it's always the money bag emoji before it. That way it's like a visual cue. I don't know, Gary, would that be enough for you to keep it simple? Yeah. If the money bag emoji is the sponsored news cue, that's one less emoji for me to select as well. You know, I got to come up with which emoji to pick. That's right. I like it. Because then it's always leading with the money bag and you can kind of spot the money bag and the money bag, obviously, hey, this is sponsored. By the way, we do love 1Password and that's cool. Like, I think that that'd be a good... Well, some people put like sponsored in parentheses in the title and we've considered doing that kind of stuff as well. And it just gets to be a little bit too noisy. But I think if it's just like the money bag, because contextually the money bag doesn't make sense until you know, like, oh, it's sponsored. And if it's always just a money bag, I like that idea. And you can just be skip the money bag if I want to. That would work. Or look for the money bag. Yeah. If there's some money for me, let me check it out. There you go. Yeah. Well, it's funny because who was I speaking to years ago that kind of changed my perspective a little bit on Google ads, which my perspective was skip the sponsored ones immediately, right? Like I do a Google search, I'm going to skip right past the sponsor to the organic habitually, intuitively, easily, give me the organic searches. And somebody who was older and wiser than me, but maybe a little bit less technically savvy, but definitely more business savvy was like, I go straight to the sponsored ones. And I said, why? And he goes, because those people are serious about what they're doing and they want to reach me. And I'm like, well, that's interesting. He's like, so they're just going to, they're legitimate. Cause they got money to spend on this exact thing I'm looking for. So I do agree with that context too. And I was like, that's actually interesting. Maybe I should click on those more often. I, you know, cause at first I was like, eh, they're just trying to spend money to get here. It's like, yeah, because they have a serious business that provides the exact thing that I'm looking for. So don't skip the sponsored look at them. So maybe sometimes you look for the money bag, you know, I think of it, I think, and I'm biased that if a company is sponsoring change log news, they are a company that is worth paying attention to. I think so. Yeah. And so look for the money bags. Good point, Gerhard. I had the exact, this challenge, I suppose, on a call this week, I was trying to showcase how we showcase people in the newsletter and I'm scrolling it, trying to find the sponsor ones. And I couldn't find it because it blended in so well. And I'm like, then I was like, Hey, don't think we're trying to blend them in too much. Cause I can't find it, but they just blend in. It's just natural. But I think the money bag being in front of it could be the easy icon because I'd have been looking for it. So it's a win -win. You can still put the thank you underneath it, you know? Yeah, exactly. Keep the same subhead. We're not trying to hide anything. That's not the point at all. You know, it never was like where these are sponsored, like that's what they're there for. It's just, we wanted to do it in a way that's a tasteful and then B allows me to write in a flowy manner, which is like throw in an H2 and H4 and move on. But yeah, the money bag for scanning. I mean, I do like the emoji for scanning. I use them a lot myself. So I think that that would be a positive improvement quote of the week, not quite so sold on like making that stand out. Cause it's honestly just a thing I made up and do sometimes. It's not like a formal part. There are no real formal parts besides there's going to be five or six main stories. And then the rest I just make up each week. Like, is there three smaller stories? Is there a list at the end that's shaped like a pyramid, you know, like I just kind of roll with it. And I like that, but definitely good feedback. Well, friends, I have something special for you because I made a new friend, Tamar, Ben Sharkar, senior engineer manager over at Retool. Okay. So our sponsor for this episode is Neon. And as you know, we use Neon, but we don't use Neon like Retool uses Neon. Retool needed to stand up a service called RetoolDB. Tamar can explain it better in this conversation, but RetoolDB is powered by Neon. Okay. They have a service called fleets. It is a service that manages enterprise level fleets of Postgres, serverless managed fleets of Postgres and RetoolDB by Retool is powered by Neon fleets. Okay. Tamar take us into how Retool is using Neon for RetoolDB at large.

So one big problem we had with Retool, we wanted users to have value production value as soon as possible and connecting to a ProDB and a new tool is not something that people will do lightly, but they're much more likely to then dump a CSV into Retool. And so, because of that, we said, okay, well, what if we just, you know, host databases on behalf of users and then they can get spin up really fast. And we really started to take off. Problem we had is we didn't have a big team. We couldn't set up a new team to support this feature. So what do we do? And so we were looking at what are the options out there? And, you know, we found Neon. Neon is serverless platform that manages Postgres DBs. And so like, okay, that's interesting. Let's kind of look in further. What's kind of really unique about them is you really only pay for what you use, which is super exactly the case that we have, right? Because we want to provide this to everybody. Not everyone uses it, not everyone uses it all the time. And so like, if we had to like, you know, us manage a bunch of RDS instances, for example, right? Like, basically we're like, you know, all in for a team to support, like figure out, okay, what are they on? How do we do? Try to have some kind of greedy algorithm to get all the data in the fewest moments as possible, right? This is now a hard problem. That's not kind of core value, right? A core value is providing that database. And we don't want to kind of want to, we know we're not like an infra team. We don't want to kind of get in that game. I think what's really great is that, okay, well, one big kind of risk when you think of going third -party is A, the cost. We're getting this free to all users. We have 300 ,000 databases right now, right? Like we can't, especially as we were rolling this out to begin with, right? We like didn't know for sure how it would, how people would respond, right? And, you know, we can't all of a sudden have like, you know, a couple million dollars, you know, at the bank for this, without kind of the activation that it has on our users.

So it's kind of obvious, but what was the appeal of Neon?

What was really appealing to Neon, it spins out to zero. And so because of that, right, it really kind of reduces the cost. And so really it's really exactly only what we spend. And there's really actually not a way to actually spend less money, even if we're hosting it ourselves. So you can be like removing all the people cost, right? Because let's say we use something like an RDS, we have to figure out ourselves, right? Basically what Neon is doing, right? How to bucket all the instances together, how to bucket the usage just to have as few instances as possible, right? To scale up and down, depending on what's going on. And now we sort of don't have to worry about any of that part, but still get kind of the cost benefit. And so really kind of was out, you know, as a win -win.

Okay. Win -win. Always a good thing. I like win -win -wins, but okay, fine. Win -win. If it were not for Neon and their offering of fleets of Postgres and how they're essentially your serverless Postgres platform, where would Retool be at with RetoolDB without Neon?

Well, we would have to have a laser fully staffed team on call burden would be a challenge. You know, and I think we have to spend a lot of time on making it sustainable. And that's, you know, a whole, you know, other sets of concerns that are, that we don't have to think about. First of all, like it's, you know, it's a team of engineers, right? Which is not free. So to everyone salaries, right? So let's say probably a team, let's say, you know, easily only focus on this and then it's saying, well, like, does the revenue of RetoolDB offset that the cost, even if just the engineers, you know, that's step one. But I think even before then, right, like you'd have to set up this team for even how the product, you know, databases and, you know, having them the way that Neon has them, right? Like suspend to zero, having, you know, warm spares that they're, you know, ready instantaneously when you like log on to Retool, those things aren't free. And even if we tried to do like, okay, like an MVP, right? Like if there's a kind of basic functionality that needs to exist, then we all have to start from scratch. And that would be a huge commitment to this. And I think we would have completed, it would, it would come out like a year later because we'd have to do a lot more validation to know that it would have been worth it right before we started here. We were able to quickly pry it out, see that it was effective and then grow it from there because the cost was very low. And that really gave us a lot of flexibility of also testing out different, different features and different flavors of it.

Okay. So RetoolDB is fully powered by backed by managed by neon, neon fleets, neon .tech slash enterprise. Learn more. We love neon here at change law. We use neon for a Postgres database. We enjoy every single feature that Tamar mentioned for RetoolDB, but we use it at a small scale, a single database for our application. They use it at scale. One single engineer propped it up, managed it. That's insane. They would have never been able to do this without neon. RetoolDB would have cost more and may not exist without neon. Okay. Go to neon .tech, learn more or neon .tech slash enterprise. So I'd like to give a shout out to Brandon Smith. Now he's not involved with Elixir pull requests 5 1 3. He is in the list of contributors. It's a one character change. He's my type of people.

Like

his comment is way, way longer than the actual change. And I love it because it has all the context. Shout out to, is it Brandon? Brandon Smith. Yeah. Good job, Brandon. He basically was just removing a hash sign or as some people call it an Octothorpe from our show titles or something. Help me understand. Yeah. It was, it had to do with GitHub interpreting the hash sign and a number as a pull request or an issue. And obviously we don't want that in the context of GitHub. So what he did, he basically fixed that. But if you check out pull request 5 1 3, there's a lot of detail. And again, I'm shouting that thing out specifically because that was a very nice contribution in terms of why he made the change, not necessarily the change, which is also great. So thank you for that, but it's the detail around it. So more like that, please. I love them. Yeah. Small change, but he made the merge button very easy for us to push because all I had to do is read all the context and I was like, it looks good to me. I like it. Merge button. Whereas if he had just opened a PR that just removed the Octothorpe from our transcript titles or whatever that is, I'd be like, what's the point of this? You know, I think he was just trying to get a Hacktoberfest t -shirt or something. In June. Yeah. It's like Christmas in July, you know, Hacktoberfest in June. So I was launching a show on Wednesday as we do every Wednesday. And I logged into the admin, Jared. You knew what I saw, right? I saw change all plus plus. I saw memberships. I saw feeds in there. I think feeds has been in there for a bit, but plus plus is new. And we're excited because we've been wanting to bring from Supercast over into change all .com proper our plus plus stuff, because it is better. It's not going anywhere. And we want to continue to Kaizen that as well. What's going on there? Right. Yes. We want to make plus plus even better. And one of the ways that we want to do that is by allowing our plus plus members to create custom feeds. So the number one request to anybody who signs up for changelog .com slash plus plus is why do I have to listen to all your episodes? Which you don't have to listen to them all, but basically the way that Supercast works, which is our platform that we've used since the initiation of this program to actually manage the entire process is that we publish a single feed to them. And then they manage the individual people feeds that you subscribe to as a plus plus member. And so the only, we only get one to them. And so to them, we send over everything, which plus plus versions, of course, which is the bonus content, extended episodes, ad -free. We send them those versions. And so as you subscribe, maybe you only listen to JS party and you subscribe to changelog .com slash plus, and you're like, wait, now I'm going to get all your shows. And we just say, yes, we're sorry about that. You can just delete the ones that you don't want. Maybe your app has a custom filter where you can just filter out just so you're getting JS party, but like that's literally our hands are tied because we don't control that platform. This is how we do it. And we've wanted to fix that problem for a very long time. And at first I thought we had to just completely ditch Supercast in order to do that. And then I started thinking how much work that would be and how we want to eventually do that and just have our own autonomy. But in the meantime, can we get halfway there as a stepping stone and give people what they want? And I determined, sure we can. All you need to know is who's actually a plus plus subscriber and has an active account on our side of the fence. And then you allow them to have a feature and nobody else to have the feature. So I started off with building the feature called custom feeds, where you can set up exactly what it's called. Log in, you can have more than one. You can pick which podcast is in it. You can pick your own album art. You can say how the titles are going to work, where it starts, et cetera, just a few different things. And then you can subscribe to that. And I've had been subscribed to one myself for the last six months just to make sure it works every time and it's working. So that's great. We're getting to where we're ready to roll that out to some folks. And so most recently, the next step is, well, how do we know who has a plus plus membership? And so that became a Supercast integration, which is actually a Stripe integration because the cool thing about Supercast, which was one of the reasons why we went with them in the first place is they say, we do not hold your customer base hostage. It's simply a Stripe integration. You own all your relationships. It's in Stripe. And so they're managing a Stripe account of ours and now we're also not managing it, but we're syncing a Stripe account of ours. And so that allows us to then suck in all the membership information into our database. And so now we know natively inside chainsaw .com who is a plus plus member and who is not, which means now all we have to do is build and enable the feed building form, the UI for building and managing your feeds. And plus plus people will be able to build their own custom feeds. And so you could have a go time feed that's just plus plus for go time. You could have a JS party feed. You could have pick my three favorite podcasts of yours, or you can just say, give me all of them and you can do all the things. And it's pretty cool. It works well. I'm excited to roll it out. We haven't rolled out yet. Cause I just got the membership information into the system. Like

this

week, was it? Yeah, this week. So that's been a lot of work behind the scenes. When I first went there, it was empty. So it was now it's full first time there. It was empty. And I was like, Oh, this is in motion. And then later than that day, you're like, Hey, I added some stuff. I'm like, I saw that when I was shipping a show. That's cool. Yeah. There's two parts to it. I mean, one is just a scheduled job that goes out, I think every three hours and just sucks in all subscription information from Stripe and updates everything accordingly. And then the second thing is the web hook system. So if you just sign up, we don't want to have to wait three hours or even an hour. I mean, it doesn't take long. I could probably run it more often. It takes like 90 seconds to run something like that, but I just set it up every three hours. And so the web hook system, so that as soon as you subscribe, we know about it and you can log in and actually manage that. One thing that's bugged me for years is you can sign into changelog .com as a plus plus subscriber. And it still says sign up for changelog plus plus because we just didn't have any connection back. And so I've already changed that. It doesn't say that to you if you already are subscribed and that's just been a, just bugged me for so long. So that's gone. But yeah, next up and hopefully by next Kaizen, we will have custom feeds, the ability to create and manage them and actually roll them out to our plus plus people, even though you'll still sign up and do everything through Supercast basically for now. And eventually we'll have a page like Supercast that will be a tier where you can, we're still not sure. We've thought about several things. I think we spitballed some ideas while we're in Seattle about ways to do that. Yeah, basically like a fully autonomous plus plus without Supercast would be the end goal. And the fact that we can now integrate with Stripe directly, like we're halfway, we have a Stripe integration. It's just not the full loop. And so eventually we'll be able to close the loop. It requires us to build a bunch of pages and emails and many of you all listening are web devs. And so all the stuff you have to build. And so we have to build all that in order to completely jettison ourselves from Supercast. The emails, there's a lot of different things that happen like, oh, your card didn't bill, the things that are all involved in managing subscriptions essentially. We become a SaaS, but not really full on SaaS, right? Like a lot of the mechanics that SaaS, it's a pass, it's podcast as a service. I like that. That is a great one. Yeah, that will stick a pass. Write that down so we can use it in our marketing copy. Is that the P -A -A -S out there already or is it a different version? That's the one. Yeah. Yeah, I get it. I get it. So yeah, custom feeds are there and they're coming to you plus plus people very soon with a trademark next to them very soon. I'm excited about this specific feature myself because whenever I do have like that change of plus plus subscription and whenever I want to listen to a specific episode, because I've seen it on the website, I have to wait for Overcast to download the others before I can go to the one that I want. And usually maybe the one, because that's like the last recent, I think one or last 10, maybe the one that I want to listen, it's further down below. So I think I was actually going to disable the automatic download. But if you're saying that, you know, this is coming, wow, this would be amazing. I can test it with Overcast specifically to see if, you know, I can only see the episodes from my favorite shows. So that would be very nice. Amazing. That's exactly how it works. Especially, I mean, so many people sign up and they say, I just listened to Go Time or I just listened to the changelog. Why do I get all these? And we just don't have, now we finally can say, yeah, go create yourself a custom feed and you can get exactly what you want and nothing else. That's so cool. Super cool. Speaking of things that we've talked about for ages, but haven't done, I have one to share. I'm going to screen share now. Okay. And I'm going to walk through as if you are here. So we are looking at pull request 516 trace GitHub actions workflows. Okay. So what this does, whenever a workflow completes, the entire workflow trace gets sent to Honeycomb. Okay. So whenever GitHub actions triggers, whatever happens to GitHub actions, we can see that. You can see step -by -step each thing. So we need to scroll down to see the picture. This is what it looks like, right? The image. All we see is like the duration. We have the ship it workflow and we can see where it's exceeded. And if you go a bit further down, we can see the various pipelines because we have a bunch of pipelines within ship it, the one workflow and some don't always run. But then what's even more exciting is that you can click on one run and you can see details about how long different pipelines took and what went in. So this specific one we have, we're looking at dagger on fly run. And by the way, this, these are the screenshots on the pull request. If you can open it up, you will see it. And it's the blue one that's highlighted and we can see how long it took to set up the job. How long, for example, it took to connect to fly, setting up the wire guard tunnel and then connecting to the dagger engine, spinning it up, all of that. And we can compare these runs amongst themselves. So what I would like to do is go to the UI now and click a little bit around. So we're getting to boards. We are in Honeycomb and we have three boards configured. GitHub actions is the last one. We have fastly content stats and fastly service stats. We won't be looking at those two. We're just looking at the GitHub actions. So we click on that. We see all the workflows that ran in the last seven days by default. We can change this to say, show me the workflows for the last 14 days. What do we see? What do we see something that stands out just in these two graphs? Duration got higher on the 19th ish. Yes. 11 minutes. Exactly. Why did this workflow take 11 minutes? That's exactly it. Like things like, why did this one take only 2 .4 minutes versus this one which took 11? What was going on here? So click on that. Boom, you get there. Boom, you click on that. You click View Trace. And within a few clicks, you go to the actual workflow. So we can see that there were some errors. We can see that this one took 11 minutes. Dagger on Kubernetes, that ran in 196 seconds. So that was good. But Dagger on Fly failed. And Dagger on Fly failed when it was actually running. 139 seconds, it was running for 139 seconds, then it failed. And then remember, always have two of everything. So then it fall back to GitHub. And that's the one that succeeded in 438 seconds. And eventually, the deploy went out. So this was, we can see it was Jared, the one that committed, so it was his commit. And if you scroll down here on the right hand side, we will be able to see a link and we have to click on the actual ship it. Yeah, that's the one. The actual run, GitHub actions run. So we copy clean, go to actually, that's what you want to go to. We open it up. Dagger on Fly, boom, we click on this. We see the build test setup. What happened? Gen server call, await tarball, timeout. So this was a timeout pulling down a package on this run. And because we tried it again in a different workflow, it succeeded. What do you think? I think that's very cool. I think that's great for actually knowing why things are happening in GitHub actions, because I always wonder like, why? Why is it not working? Cool. So while I was like, looking around the whole Fly world, I came across this. I came across the blog World Page Speed Test by none other than Chris McCord, the creator of the He again, he is our type of person, for sure. He tinkered for one afternoon. He took Elixir, Flame and Fly and introduced world page speed dot fly dot dev, May 8. So not that long ago, very recent. And it's a great read. But we'll skip over that, right? Because we're not interested like right now in this context in the details. We want to see the finished result. World page speed dot fly dot dev. What is the first website that we're going to test? Change .com. Of course, that's exactly what I did. That was the first website which I tested. So what it does behind the scenes, it connects to a couple of data centers, Fly data centers, and it loads the website, the change .com website in a Chrome headless browser. So this is a full like DOM interactive sort of situation. And we are looking at Frankfurt, looking at Hong Kong, we're looking at Chicago, Sydney, Tokyo, Sao Paulo, Santiago, and Mumbai. So it's as if you could read running speed tests for a website from all these places. This is really cool. So what do we see? Germany is a bit slow. Hong Kong is a bit slow. Just to add more detail, changelog .com, when it loads on this headless browser that is running in Frankfurt in a data center, a fly data center, took 1400 milliseconds to load. That's a bit slow. So I'm wondering if you reset it. Not for me. So click go again, you know, second time it's a bit quicker. Okay. And this shows you the caching. Oh, that's why mine was slower then because I pulled up my own page and did the same thing. And mine was 494 milliseconds for Frankfurt. And yours was 1400 and something the first time. Okay. That makes sense. The first time. So now you can test caching. So this is more realistic 575 milliseconds, right? Once the cache is primed, which cache? The Fastly cache, because this serves it from Fastly, right? So we can see that. So this is pretty cool, but I'm wondering how does it compare when you go directly to fly, right? So we're going to the fly origin, which is running in the fly data centers, but from these remote locations, they have to traverse the fly network and they have to end up in Virginia, right? Where the fly of where, where the changelog application is running. So let's try that. Let's do fly .dev. So if we're loading the website directly from the origin, this is what we can see. So it's not that much slower, 648 milliseconds, somewhat slower, but not that much slower. I thought this was interesting. I like how you had this like a subtle jab, this segment here. We won't say why, but let's just say it's a subtle jab again. Yep. So

let's

keep going. Let's keep going. So how does Muse Y Combinator compare? It's slow, right? 850 milliseconds. Yeah. So it's way smaller too. It's changelog. Yeah, it is. It's changelog faster than Y Combinator. Looks like it. It looks like it is. So that's good. And they're sending probably a 15th. Yeah. I mean that's a 52 kilobyte page. That's tiny. I know. Right. So what's going on there? Still taking a while. Yeah. I'm just going to go back and I'm going to reload it again. There is all text. So it makes sense that there's pages small. I know. Right. So yeah, 850. But they must have slow CDN. Yeah. If there is one at all, or maybe they just exist in one server somewhere. Yeah. It looks like that. Fastest in Chicago, Illinois. 315 milliseconds. So they probably have a US -based server. It's probably not at all distributed around the world. How does Google .com compare? I have to check myself, right? What? Google is slow. Google .com. It's like, I don't know what's happening here, but yeah. Maybe this is Chris's tools having problems. I don't know. Although similar to Hyperping. I mean, that's what I thought of when I first saw it. It was like, this is like Gerhard's Hyperping service basically. Yeah. But right there, the browser. Yeah. So Sydney is especially slowing for Google. 2000 milliseconds. I doubt that that's true. Can they continue to make money with that being true? I don't know. 2 .262. That's two full seconds. That's two full seconds. To load Google .com in Sydney, Australia. I mean, they're surely losing money. Yeah. So from a fly node in or near Sydney, right? That's how it works. It runs like in a data center around Sydney.

That's

non SSL though. Does that matter? HTTPS versus HTTP? It is. I'm saying. That's why upgrading. I'm saying HTTP. I mean, yeah. I mean, I can try HTTPS explicitly. Well, I just noticed that it doesn't do that when you just type in like change all the content of the domain. It's not defaulting to secure. I know that we have a redirect and yeah. Yeah, we do. Well, they probably do as well. It'd be cool to have this tool as traces back into Honeycomb like you did. Like it'd be cool to like have the, to like a service like this as opposed to pick the place that matter most to you. Not so much matter most, but like ones you want to make sure, okay, what are ups and downs in Australia? Like how frequently are we slower than we want to be and track that similar to the way you do with GitHub actions and traces and that whole flow, which I didn't chime in too much there, but like that was just magical. How you can like stack trace essentially where in the bottleneck of GitHub actions, deploy a deploy fails. That to me is like super magical to have that visibility, but the same kind of visibility into page speed, especially if we care so much about it because I think we do. Yeah. Go back to that Google one because there's some interesting results on that Google one. Yeah. Going back to the Google one. So

in

Frankfurt, Germany, it took 800 milliseconds. That page was 1 .4 megabytes. In Chicago, Illinois, it took 775 milliseconds, which is faster. The page is twice the size. Yeah. I don't know what's going on here. What are they serving to us United States folks? Do they know we like it super -sized? Is that what they know? Maybe. I don't know. Tokyo, it's again like 900. Tokyo is like the smallest one. And then in Brazil, it's large again, but it's faster. And then in Chile, it's large and fast. There's like, they have different payloads based on where you are

to

a large degree in terms of data. I'm wondering if they're like serving like the, you know, like, like the cookie notification, you know, that like when you load Google for the first time, you have to accept to some cookies. Maybe that has something to do with it. I don't know. That would double the size of the page, but yeah. But I'm wondering how does bunny dot changelog fair? Is it still a thing? Yeah. It's still, it's still running. Okay. You can check it out a little faster. Yeah. It's 300 milliseconds, 400 milliseconds stick. Pretty good. I think. I think this is this, this is, has been the fastest one so far. Cool. So Chris, we. Why do you got to open up old wounds, Gerhard? We want to know more. Well, you'll understand in a second. We're almost there. Oh my gosh. Oh gosh. Okay. Well, it's happening. It's happening. So what's happening? I agreed to call Jared and Jared was saying on the last Kaizen, I like the idea of having this 20 lined varnish config. Yes. That we deploy around the world. And it's like, look at our CDN guys. Yes. Pie dream. You got there. Did you get there? It's so simple that it can do exactly what we wanted to do and nothing more, but I understand that it's a pie dream. I'm still quoting Jared. I understand it's a pie dream because that varnish config will be slightly longer than 20 lines. And we'd run into all sorts of issues that you end up sinking all kinds of time into. So by the way, I think I have a title for the show. Not a pie dream. Not a pie dream. I like that title. So if you, if you introduce pipedream .com, it's not that. Okay. So if you make this mistake, that's an honest mistake. Pipedream .com is a thing. I got, there you go. Pipedream .com is a thing. I didn't even know. Oh wow. It's actually like a developer service. Yeah. Connect APIs, AI. There you go. I thought this was going to be the first day of the show. Well, they have to put that in the hero. This thing has almost 8 ,500 stars on GitHub. This like a legit 8 ,500. Yeah. This is a, so yeah, it has a video and all 800. Not what you built. No, this is not it. This is not it. Get off this page. Okay. So you just need to do pipe dream changelog .com. Okay. You can load it. You can try it. You can load it. Yeah. And I'm going to share something else while you load it and while you look at it. Okay. Okay. Very excited. Well, I'm glad I kept the last for best. Sorry. The best for last. That's what's happening here. This is the grand finale. That's a good title too. The last for best. Cool. Okay. Can you see my, my terminal? Yes. Okay. Can you see that? What did I type? LS. Perfect. That's exactly what I typed. Cool. A weird quiz. A weird choice. So here is a run script. Okay. It looks fancy. It's executable and it can do a bunch of things. So what we're going to do today, we're going to run demo 2024 06 2021. That's what we're doing right now. Cool. And by the way, this is coming in the pull request. So by the time this is out, you should be able to see it. So let's keep going. And you may be wondering, Hey, this is not the first demo. There was another one. Back in January. Back in January. Yes. When you guys ran into problems. When, yes, exactly. With, with James. You and James Rosen. Yes. The video is out. Let's build a CD and you can check it out. The exact problem, what we ran into. Okay. So that was the first demo. Now we're doing a better one. Cool. We hope so. Let's see. So we're looking, we ran HTTP stat, which I love it. It's a tool built by Dave Cheney. I'm not sure how to Dave Cheney from the Go community. That's the one. Yeah. HTTP stat, the Go version. And it gives you a breakdown of the request to an HTTP endpoint. So we can see all the headers and we can see how long the DNS lookup took. Two, two milliseconds. The TCP connection took four milliseconds. The TLS handshake took eight milliseconds. Server processing 573 milliseconds. That took a while. The content transfer 727 total time for the pipe dream to load 1 ,300. That's a bit slow, right? So let's keep going. So what was happening is pipe dream was only running in Sydney. And now we're going to use the magical fly to scale it around the world. It will run in 16 regions. Yes. Yes. You approve. I like this. So let's scale it. To narrate, there was a prompt that asked him yes, no. And he said, yes. I said, yes, I'm ready. Bring it on. And that's what's happening. Boom. Executing. Done. The machines are up. They're running. And we have a question to answer. How many dollars do you think this is going to cost per month? There's emojis. There's everything. That's going to be a lot of dollars, I think. Do the big cash bag emoji. Can you see that? 30 bucks. 30 bucks. Not too bad. So this is just for the instances themselves, just to be clear, right? Not for the bandwidth. Yeah. Not for the bandwidth. We're only using the memory 256 megabytes of memory, but one instance per month costs $1 .93. 16 around the world, $31 per month. Plus bandwidth, maybe taxes. I don't know. Plus or minus 10 bucks. So let's do that again. And let's see what happened. Ooh. 369. And what do you see there? X cash miss. So this actually was served very close to where I am. Right. But because it was a miss, it had to go. So this was a cash miss and it had to go and fill it. We can see the TTL. This will be considered fresh for 60 seconds and it's going to be considered stale for 24 hours. That's how this is configured. Cool. We keep going to the next one. So what I'm using now is a tool. I love it. A CLI used OHA. O -H -A. It's from the cargo community. And it will run a latency test on endpoints. Right now we have it configured to send 30 requests for one client spaced one second at a time. To see the latency distribution for this HTTP endpoint, to see how many succeed, how many fail. It's end curses. It's beautiful. There's bars. There's green. There's yellow. You have to try it out. So what do we see? We see that 26 out of the 30 requests took 38 milliseconds. Lovely. Isn't that nice? The slowest one was 300 milliseconds. 300 milliseconds, yes. You will always have some outliers. And the fastest one is also 8 milliseconds. I think we can ignore them because you always get one which is super fast and you always get one which is super slow. Maybe there's something with the tool, but the bulk of the request, like the majority of the request, took 40 milliseconds. And this is pipe dream. This is a pipe dream. It's not a pipe dream. I don't think it is. I'm beyond tickled. I want to see the code for this. I want to see my 20 lines of varnish. We're getting there. We're getting there. So the next thing we have to compare this to changelog .com. We're doing the same measurement. We measured pipe dream and we went to pipetream .changelog .com to see the webpage. How it loads. So now we're doing the same speed test, same OHA, 30 requests, one client, one second apart to changelog .com and in a few seconds we will get the result. How is this going so far? This is going great. It's visually impressive. Amazing. I was like this brought me so much joy to put together. This was just like the best. 48 milliseconds. So changelog .com, same test, same tool, same everything, 10 milliseconds slower than the pipe dream. This is what you're asking for, right? It's almost as if I could tell that you're going to ask this. How many lines of varnish config? That's what we want to know, right? That's exactly what I want to know. So we're counting. We're seeing 43. We keep going. 91, 117. However, there's a lot of comments, a lot of to do's, right? Like it's a well commented config. 117 in total. How many lines of varnish config without comments now you get to guess? 91. 91. Jared? 47. 46. 46. If there were any prizes, you would get it. 46 lines of code. 46 for this whole thing. Cool. That's amazing. So that was it. That was the end of it. So that's pipe dream. It's varnish config that's deployed to 16 fly machines around the world that when you go to pipe dream .changelog .com, it is a proxy for changelog .com. It's actually varnish. It's a varnish configuration. It's just that varnish configuration just running around the world. When do we ship it? Exactly. And it got down to what was the milliseconds in the sub -100s, right? Like 30 something? 38. You know what? If only there was page speed. Let's try it, okay? So I'm going to share another screen. Back to page speed. Let's see how it loads. How does it compare? World page speed, yeah. So how does it compare? We see bunny here. So we're going to open another one. Let's change google. pipe dream. changelog .com. https. We're going to https. No redirects. Nothing. Let's see. 700. 500. 436. This wasn't cached right in some regions. So let's reset and let's try it again. Let's try pipe dream again. What do we see? 400 milliseconds. 500. 300. 300. 457. If only, if only we could see this over time, right? So let's see. What do we see here? So we see again, hyperpaint. We do have it over time. 24 hours. Last 24 hours from a bunch of locations. Average response time 140 milliseconds. I love it. Let's ship it. Let's ship the pipe dream. So hang on. We keep going. We keep going. changelog .com is 312 milliseconds. Same test, same everything. So twice as fast as changelog .com worldwide as measured by a tool that was made for this. So before we ship it, before we do that, there is, there is the challenges, right? Cause like there's still bandwidth costs. Yeah. There's other things we have to do. Oh yes. I'm just, I'm being excited. Yeah. This is amazing. That's a very basic varnish config, right? I'm assuming that's not handling any of our specific rewrites and needs and all that kind of stuff we have in Fastly right now. Correct. Yes, that's correct. Also, we're not serving any static content. So that's one, but maybe we can leave that for later. Maybe we can just serve the website. We're not sending any logs to Honeycomb and we do want that configuration. There's one thing which we still have to figure out. For example, when an application gets redeployed, for some reason, the backend, as it's called in varnish, remains sick. So this is varnish term, right? Which is the backend, which is the application. When there's a redeploy and there's a recon, when the application shuts down and restarts, the backend remains sick. I'm not sure why it's happening, but obviously we need to fix that. There's no feed proxying. There's like a bunch of things like that. And if you want to purge anything, we still have to have a system that purges across all these varnish nodes. So how do you, because you can't just purge one. So the question is, do we want to continue with this pipe dream? I would like to. Adam, what do you think? I'm torn. I don't know. I think it's, we have to weigh it against the whole, should we, should we buy it or should we build it? Right. That's the question really is here. We're saying we should build it because we can customize it to our specific needs, but then we have to maintain it. And then we have to find a way to pay for it, which may or may not be something that we can get given to us, so to speak, as part of a partnership, which is how we've done it before. So there's definitely some, there's some in dreamland, I think as a pipe dream officially, it does make sense to pursue because it's the, it's the itch, right? It's the scratching our own itch back to the really simple CDN idea we came up with four kaisens ago. I don't know. That's kind of what this is, is like, can there be a version of this that doesn't have to be, not so much that the cloud flare cloud fronts or fast leaves or bunnies or anybody else out there is a bad or a good thing, but like if you can build it yourself, I think that's the question. Like if you could build yourself and maintain yourself and fine tune it and it's worth it to you, is there a way you can go your own route? And I think that's where a really simple CDN comes into play where that's really what we want. We don't, we don't want all those bells and whistles. I mean, the purging thing is probably the most pertinent thing because we do purge frequently enough when we have misses or issues or whatever, but that's a frequent feature. Otherwise it's what nodes and regions matter to us. Can we monitor their speed and fastness and do we, can we fine tune the system we've built enough to eke out every millisecond possible? I think the answer is yes, but the question for me is how we pay for it. I mean, if we can figure out how we pay for it and make it not so much profitable, but make it something that bakes into our core story, like we have done in the past, to me, I think that's a win -win and I prefer triple wins, win -win -win. With win -win -win, we all win. The answer is, when it comes to paying for it, is that this would be within the fly sponsorship. We wouldn't exceed it. You don't think so? If we don't, if we don't handle the static content, because that's, that's where the bulk of the bandwidth is. Even if we handle the static content, right, even if we serve the static content through this, even in that case, we would maybe exceed it by a little bit, but we'll still be like, we'll be right there at the limit. And this limit has been in place for a couple of years now. So maybe that's a flooded IO conversation, but it's, it's not, it's not twice as much. We're not talking twice as much. We're talking maybe, maybe 50 % more, maybe. Yeah, I think you said before we do like 20 terabytes of bandwidth a year, is that right? Was it the number? Maybe a country member would need to check the numbers, maybe. Yeah, thinking here on the fly on the podcast is like podcasts as negotiation. Like we just, we need to revisit the fly conversation basically and see if this is interesting to them. Because I think for, there's two, two sides of this coin in my, from my perspective, is one, it's, I guess three. One, it's super cool. So BA, right? This is awesome. That's my abbreviated version of bad something else to keep our show clean. Then two, I think, should we build it and should we maintain it? Is it, what is the maintenance burden we're taking on to build and deploy it? And is it literally just enough in maybe a couple of iterations to be exactly what we want? So should we build it? Should we maintain it? Is one question. Then the other question is, can we have a partner love what we do enough to sponsor it or to bring it into the fold we already got? Seems like the first one's a yes, cause like it is awesome. And the third one's a possibility cause it's within the range. And I think the middle one is probably one to maybe spit ball right here, which is you've built most of it. How like, is this 80 % of it? Is, is there 20 more percent? And is that the hard part? Like how close to a version of done is this? To be honest, it feels like, it feels like we're 50 % there. It took me some number of hours. We're even talking days. We're talking hours of effort so far. So it was nothing massive. It didn't take me like days and days of like wrestling with this. There are a couple of challenges. I am curious about this myself because I think it's really cool to be able to build your own CDN on top of Fly. Kurt blogged about this years ago and he was using Nginx in that context. I think we would be fulfilling, not a prophecy, but the story, which is we're using Fly the way it was meant to be used. We're using Tigris as well. R2 migration, maybe, who knows? I don't know. I'm just dropping it as an idea. But if we use Tigris for the static content, and if you use this for the dynamic content, we may have a winning proposition. The only unknown is the logs. So that's the one that, but now we have full control over that. We're not like, maybe we can do it. No, no, we can definitely do it. It's just a matter of spending some hours to figure it out. Well, I think that, as I said last, Kaizen, there is a halfway there similar to my halfway off supercast move, which is we leave cdn .changelog .com alone, which has the bulk of the bandwidth and has the logging issues and has all of that stuff. And we just focus in on changelog .com and the feeds and just a straight up content cache for the dynamic pages. And we see if we can, with purging, and we see if we can tackle that. If you can tackle that, because we need purging on feeds, for sure. If you can tackle that, you're halfway there and you're way further than you are now. And once we get this into a place where it's like, it's a varnish config that I can author and test and try out, then I think that it's a lot more something that even I could take the last mile because I can figure out some of that stuff. The purging is definitely an issue. Do we have to have some sort of orchestrator or something that you notify, hey, it's time to purge. And then that thing trickles it down to all these little varnish caches versus the app knowing all the varnish caches. There's some sort of middle piece of layer in there that we have to figure out. But the rules around the feeds and all that kind of stuff, if we just focus in on that and leave the cdn .changelog .com alone, then we learn a lot more. We build something that's continually cool. And in the meantime, we can figure out your other questions, Adam. Do you guys agree those are the three kind of pillars that are hinging upon? Like one, it's awesome. Two, should we build it? Should we maintain it? And three, can it be, you know, what's that called? Not endorsed, but provided by, courtesy by kind of thing, you know, whenever a brand gives you something and you do something with it and it's not really... Can't afford it. Yeah. The way I think of this is simple. And we come back full circle to where we started. Fastly is a bidet. How do you pronounce it again? There

you

go. It squirts, it remembers, it does the water, the whole thing. Okay. Okay. I keep going. I'm tracking this analogy. Pipe dream is a wet wipe. It's simple. It's practical. Take it anywhere. Save experience. This has gone too far. I go, there's one more step. There's one more step. He's gone one step further. No CDN, singles ply. Single ply? Oh my goodness. We're off the rails now. That took me all day. That took you all day. That took him longer than it took him to make pipe dream was to figure out that analogy. Exactly, it did. That's hilarious. So I got a proposition here then. I think this is an end point to some degree. I love your end cap by the way. This is a good laugh. But I do have one more question that I think might make more sense potentially for plus plus. So is this roughly where we want to end? Because if so, then I have a potential five minute, eight minute plus plus. I think this was definitely the crescendo. Okay. Well, let's pause a second and say that demo that you did was definitely like the fourth of July here in the United States, whenever it's the finale scenario, like the skies were a blazing and it was thunderous. For those who didn't see it, we'll throw some screenshots. Cara, pull some screenshots if you can

of

that so we can throw them in the show notes because I think it was super cool. It's worth seeing. And I think that for the plus plus folks who are subscribed, boom, there you go. You're getting a little bonus here in a minute or two. For those who are missing out, you're just missing out. Go to changelaw .com slash literally plus plus or words plus plus. Don't both redirect your plus plus the words. They both work. You can spell it out. You can use the characters. Either way, get there. It is better. It's better. Ten bucks a month, hundred bucks a year. And see what we're going to do with this CDN, this saga. It never ends. There's subtle jabs in the middle of the shows. There's finales at the end. There's pipe dreams. What more do you come here to change all our friends, Kaizen edition for? I mean, this is what you come for, right? That being said, we done? Yes. Kaizen. I had so much fun. Three years in the making. It's only getting better. Only getting better. Yeah, man. I love it. Good stuff. Bye friends. Well, well, that was quite the demo. If you'd like to see what we saw, we are working on extracting that bit as a standalone video, which we'll post to our website at changelog .com slash changelog. Of course, I'll also link it up in news. And if you haven't subscribed to the newsletter yet, head to changelog .com slash news right now and read our 29 reasons to subscribe. Yes, there are now 29. And then after you read them, just try not to subscribe. Go ahead. I'll wait. Back. Okay. Thanks once again to our partners at Fly .io, to Breakmaster Cylinder for keeping our beats so fresh and so clean, and to our friends at Sentry. Don't forget that coupon code changelog, save 100 bucks off the team plan next week on the change log news on Monday, Carol Lee, PhD talking code review, anxiety. Sorry. Not sorry. On Wednesday and on friends. I'm not sure, but I do know it'll be

have a

great weekend. Share the change log with your friends who might dig it and we'll talk to you again real soon.