The Changelog: Software Development, Open Source - Kaizen! NOT a pipe dream (Friends)

Episode Date: June 28, 2024

Welcome to Kaizen 15! We go deep on the big Changelog News redesign, give shout outs to folks who've helped us along the way & Gerhard takes us on his journey to turn Jerod's pipe dream into a reality!

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 Cronitor 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. Cronitor.io. Check them out. Join 50,000 developers Cronitor.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 Cronitor, and you should too. And here's how easy it is to install and use Cronitor to start monitoring your crons.

They have a Linux package 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 latest activity 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 Kaizen-ing once again.

Kaizen 15 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. Kaizen 15. Friends 50. Adam's here. Jared integer here. Nice round 50. So here we are. Kaizen 15, Friends 50, Adam's here, Jared's here, Kira'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 bigging 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 so yeah you've already impressed me jared oh good paying attention to that repulse 3u have you pressed 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 uh just a heads up we will be talking about b days towards the end okay okay so heads up very short very short but there will be a short b day conversation but oh you have

thoughts on the days yes i thought you're kind of i thought i thought about birthdays like you shortened it to b-days no no no it's just how I pronounce it I'm glad that you know what it means so you listened to our friends episode with Kelsey Hightower I really enjoyed it 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 because we have more important stuff to talk about take us on a ride Gerhard we will start somewhere Let's save that to the end. Yep. Because we have more important stuff to talk about. Yeah. All right. Take us on a ride, Gerhard. We will start somewhere, which is, I think it's related to Jared, I think.

But maybe it's Adam as well. So as you pointed out, Jared, I do like round numbers. I do like dates. Yes. I 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 Ship It show. Was it your last episode? Episode 90?

No. No, that was in January. You're stumping me. I don't know. It related to Ship It show in June. Was it the original ship of Ship It? So anyone with a terminal can verify this. Oh, gosh. You can do who is shipit.show.

Oh, we acquired the domain, maybe. We created it. 21st of June, 2022. That's when shipit.show. I don't know how you know that. How do you know that? Just random. I was paying attention to things.

You have a list of dates that you put in your diary and you're like, June 21st is now important to me because Shippit.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,

Shippit.show became a thing. So the actual domain. So that was nice. That is nice. Cool. 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 Kaizen's 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. Ship it, show episode 10, ShipIt.show 4 slash 10 and you'll see it. And they 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 change log setup on a regular basis and then talk about it. So the pace was every 10 Shippit 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. I did a little digging into this extended version of 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 a part I like. It says, the concept of Kaizen involves all employees, from top to bottom, all of 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 Kaizen has – 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 Shippit 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.

And I think this is very much Gerhard-born but adopted 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 as all three of us we've never done it on like separately so from the beginning this has been the secret formula and there's 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 aid to meditation. So you're contemplating the basic principles of the cosmos and the human nature.

Okay. Check Wikipedia. So, on follow skeptics, it's Greek. That's where it comes from. Naval gazing. Jared here, in the editing room. You know, I thought

Onfalo Skepsis 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, Onfalo Skepsis was our word for round three in the Pound to Find 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 you know they do have more hair yeah so i think kaizen is a better name i think uh yeah i like kaizen i quite like that yes i do as well let's put a new spin on navel gazing though for me because like uh it's it's generally been a frowned upon term well it's something that you do for you do for yourself by yourself and so navel gazing i think

in public is where it becomes frowned upon i like that you can stare at your own navel all you want and if it helps you with your thought process and your 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 yeah 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. That 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 kizen is a much better way of framing it so it feels okay here's maybe a better twist on it is if you're gonna navel gaze turn it into a product and 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, in 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, you know, 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. So, you know, 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, right? 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, you know, 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 and 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've skipped forward through the navel gazing part. Yeah, chapter break. Came landed here. So what can you expect in this episode? The first thing I'd like to give kudos to some people in the open source community. Okay. They did some great work.

I'd 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. We have lots of stories to share between the three of us.

We will share those stories. No peeing in pools. Remember the last one? No peeing in pools. And most importantly, we want to celebrate the wins. We had quite a few. Naval 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 did 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. It's been a while.

I normally just push straight up on the master branch. But I thought, this is a noteworthy change. I should open a PR and Gerhard's going to love this. I did. Oh, man, I loved it so much. Kind of pandering. 510, pull request 510. If you go and open up GitHub, our GitHub,

the changelog, changelog.com, news redesign. Oh, yes, baby. That was amazing. By the way, baby, I'm only using it, you know, as an endearment. The fact that it took nine months has nothing to do with it, okay? This is not your baby.

This is not my 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 other background stories, any of the things that you want to share about the news redesign, Jared? 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 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 podcast 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 It's page, just like JS Party's page, etc. 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 would 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

change.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 frail, frail, frail. Sorry about that. Frail, uh, 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 being able to hear from and see some of the people who take value in the newsletter I think is powerful two things you want to know

A. do people like this? B, what does it look 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 the newsletter jared i i really enjoy it yes i have clicked on the view in browser button and i noticed uh i think i think until about 90 right like issue 90 it had the previous design that was uh devin's upwork side

hustle exposed 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 4 slash 90, 4 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. maybe you've done it by design maybe you knew what you were doing but in this case the previous issues have also improved so when you ship the new 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 so yeah if you if you haven't seen that link in the email click it and check it out otherwise changer.com forward slash news forward slash 90 yep so i have a question and i'll go first okay okay okay so 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, 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 direct 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? That's it. It's very important. It's only my birth date. That's a very important number.

Only my birth date. Did you add two reasons or did you just change the text? Okay. No. Oh my gosh. Scroll, scroll. Yes. Oh my gosh. 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. It did. Okay, my bad. Still there.

Well, it goes in like, it's a graduated scheme. It's a pyramid scheme. it's using the pyramid scheme i like that i like that because i've actually 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 right 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 I'll accept this. Cool. And for everyone else, there will be a new pull request. 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. I want people's quotes on there. And then B, we do a few things differently and they're all minor. It's like minor reasons. But I want to have somewhere a list. And then B, we do a few things differently and they're all minor. It's like minor reasons.

But I want to have somewhere a list of 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 way too many of them and just made some up? And he actually stubbed it out with 36 reasons. And I took it as a personal challenge to come up with 36 reasons why you should subscribe. And I'm like, in the mid-20s, I'm like, Cody, this is too hard, dude. I cannot come up with it. He's like, I did not expect you 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 cannot 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, uh, and left it there. But I love that you've improved it. You've added two. 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 reasons. Yeah, I mean, you have to subscribe

if you read 99 reasons, don't you? Yeah. Hit me. Excellent job here. I will happily watch this. 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. I've 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 5, 10, 20 years. It's so complicated today. Put together a simple form with a submit button, have to 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 you got to disable it when it's, you know, is fetching is true. And then when it comes back, you got to enable the button again, or 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 ritual takes that all away. And so really, I think the core reason why some of what user ritual 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 back end 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 back end. 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, you know, 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 know, 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 in the cloud, make custom SSO, audit logs, 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 that we shipped in the last Kaizen, which is I'm connecting to Neon from my local environment, right? Okay, yeah. Look at this. So I've done this. I've created a branch. I think it was, I don't know, a few days ago. I can't remember.

And obviously, master has moved since, right? So if I'm going to go to, I'm going to close this if i'm going to go to i'm going to close this i'm going to go to home localhost 4000 and if we go to the podcast securing github 2024 06 19 right all 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 okay yes that 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 come back. So fast. I refresh.

Polypane. Boom. Bam. Look at that. That's cool. Cool. So that was it. All right.

That made me very, very happy. That is cool. 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 to subscribe. It can be the same. It's okay. The other 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 showcases the content and the reasons and the ability and the social

proof all in one place. This divided design was like, I know our newsletter, when we first talked about it early on, before it got into code or dev or really some fleshed out design, we were talking through the newsletter could be on the right and the left side can be static and you can easily scroll on the right and it matches the brand 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 my i mean continuous improvement i'm still holding out i mean gerhard knows the exact date that we bought ship it dot show right like yeah when we get changelog.news and i i can stop saying dot com slash news i mean that's going to be a huge win and someone out there who holds that domain and needs negotiating power better not listen

to this because when I talk to them I'm totally going to play it cool like hey 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 dot 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 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 is it 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 a 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 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 realize he's a villain

and it's probably not the best association, but 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 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, 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.

And now it's kind of a unique thing. You also can't 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? Cause 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 buttony besides like literally a play button. I don't know. There's 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 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. You're not being in it. You're just making it. We are improving it for sure. This is amazing. I hope it has to keep going. You're napping in it. You're just making it. We are improving it, for sure. I appreciate it.

I appreciate it. I guess a 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? Yeah. Okay. So I have a branch and I was just basically synchronizing it with all the data

that's in the parent branch. 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 get you back to where you were. It's one way, yeah. That's what you want, yeah. Exactly.

I'm still a little tentative of those things because 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 I'm 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 production branch and then your dev branch and you're doing stuff and you're like, am I sure I'm not connected to the production branch? It's a little anxiety ridden for me still. 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. Well, there are backups. The whole point is, 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. 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 doing stuff and I'm just one of them.

That's why a well designed system really helps. Yeah. For example CDN you only upload. You don't allow 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. Sliding into the conversation. Yes, that's really smart. Yeah, that's interesting that you have keys to unlock

but not keys to lock. That's kind of like the concept. I have that's really smart. Yeah, that's interesting that you have keys to unlock but not keys to lock. That's kind of like the concept. 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 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's 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, 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, 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, right? 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 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 the 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 as a gift yes you did fresh data

something about booty no no no just fresh data yes I do recall something about that so yeah okay so yes you did i have something else for you though okay it's not ready is it called more booty or double booty or it's called something it's called pipe dream it's called a pipe dream it's called my dream cool let's let's hear it so uh we're not ready for that just yet we still need to stay like in in the news redesign camp for a little bit longer i do because i was going

to share a couple of things that i think would make it better okay so first of all is 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, 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 sponsored sections, just like a fainter gray or fainter, whatever. Like it has to be tiny. Like it shouldn't be, you know, it's not an ad because it's not an ad, but it's slightly different. Also the shout outs. I think if 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 outs? Are you talking about when I give Change.log++ shout outs? Quote of the week. Oh, quote of the week.

Yeah. I think also like a different, 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 terms, which is basically in raw markdown without any sort of additional tooling. And so the only special formatting that we do is on the sponsored posts. That's an H4, I think, when we give a thanks to 1Password for sponsoring ChangeLog News. And we just style that differently, literally because it's 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 in a timely and enjoyable fashion. And so 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 quote of a week is literally me making an H3 that says quote of the week and then a block quote. And then that's it. Like that's what the quote of a week is literally me making an h3 that says quote of the week and then a block quote and then that's it like that's what the quote 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 quote of the week is not always there which is i think it's funny like there's not always a quote of the week there's not always a video of the week so it'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 quote of the week block.

So it's more or less 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 – and 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 Jared had said, like it's not something special and then adding a thanks to 1Pass for sponsoring the 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 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 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 just a, it is just a personal preference. Yeah, it's good feedback. No, good feedback. 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 thanks for sponsoring ChangeLog News, we put the cash bag emoji. Most of our actual sections and breaks is horizontal rules and emoji. And so the quote of the week always has the exact same emoji 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 publishing workflow. Yeah, maybe always just putting the, like for example, to read the headline, strong, unique passwords for you and your team.

That was the one password 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've 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. I think that'd be a good... Well, some people put like sponsored in parentheses in the title and right 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 you can just be like money back skip the money bag if i want to that could work or look for the money bag. If there's some money for me, let me check it out.

There you go. 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. 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, cause those people are serious about what they're doing and they want to reach me. And I'm like, oh, that's interesting. He's like, so they're legitimate because they got money to spend on this exact thing I'm looking for. I do agree with that context too.

And I was like, that's actually interesting. Maybe I should click on those more often. Because 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 sponsor, look at them. So maybe sometimes you look for the money bag. I think, and I'm biased, that if a company is sponsoring ChangeLog News, they are a company that is worth paying attention to. I think so. And so look for

the money bags. Good point, Gerhard. I had the exact 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 because 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 would have been looking for it. So it's a win-win. And you still put the thank you underneath it. Yeah, exactly.

Keep the same subheading. We're not trying to hide anything. That's not the point at all. It never was. These are sponsored. 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 because 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 Engineering 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. They have a service called Fleets. It is a service that manages enterprise-level fleets of Postgres. Serverless managed 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 in a new tool is not something that people will do lightly. But they're much more likely to then dump a CSV into a tool. And so because of that, we said, OK, well, what if we just host databases on behalf of users? And then they can get spin up really fast. And we really saw that take off. Problem we had is we didn't have a big team.

We couldn't spin up a new team to support this feature. So what do we do? And so we were looking at, OK, what are the options out there? And we found Neon. Neon is a 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, you know, RDS instances, for example, basically we'd have a whole infer team to support, 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. This is now a hard problem. That's not kind of a core value, right? A core value is providing that database. And we don't want to kind of go into, we know we're not an infer 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 giving 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 people would respond, right? And, you know, we can't all of a sudden have like a couple million dollars, you know, at the bank for this without kind of seeing 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'd be like removing all like the people cost, right? Because let's say we use something like an RDS,

we have to figure ourselves, right, basically what Neon is doing, right? How to bucket all the instances together, how to bucket the usages 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 it 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-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. I think we have to spend a lot of time on making it sustainable. And that's a whole other sense of concerns, I think we have to spend a lot of time on, you know, making it sustainable. And that's, you know, a whole, you know, other sets of concerns that we don't have to think about.

First of all, like, you know, it's a team of engineers, right? Which is not free. So it's everyone's salaries, right? So let's say probably a team, let's say, you know, eight to 10 people, you know, easily only focus on this. And then it's like, well, like, does the revenue of RictalDB offset that, the cost, even if it's just the engineers?

So, you know, that's step one. But I think even before then, you'd have to set up this team before you even had a product. Databases and having them the way that Niant has them, like suspend to zero, having warm spares that they're ready instantaneously when you log on to Retool, those things aren't free. And even if we tried to do like an MVP,

this 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 completely, 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 try 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 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 ChangeLog. We use Neon for our Postgres database. We enjoy every single feature that tamar mentioned for retool db 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 manages 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 Brandonon smith now he's not involved with elixir pull request

513 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 Brendan? Brendan Smith. Yeah, good job Brendan. 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 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 513, 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? I think he was just trying to get a Hacktoberfest t-shirt or something. In June. Yeah. It's like Christmas in July, Hacktoberfest in June. Yep. So I was launching a show on Wednesday, as we do every Wednesday, and I logged into the admin, Jared. You know I saw it, right? I saw Change.Log++.

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.Log.com proper our Plus Plus stuff because it is better. It's not going anywhere anywhere and we want to continue

to kizen 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 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 JSParty and you subscribe to changelog.com. 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 JSParty. But 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 etc 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 GoTime feed that's just plus plus for GoTime. 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 it out yet because I just got the membership information into the system like this week, was it, Adam? This week, yeah. Yeah, this week. So that's been a lot of work behind the scenes. When I first went there, it was empty. So now it's full. First time there, it was empty.

And I was like, oh, this is in motion. And then later in that day, you ping me. 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, 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 webhook 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 webhook 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 were 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 you know all the stuff you have to build a bunch of pages and emails and, you know, many of you all listening are web devs. And so, you know, 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, you know, 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. It's a lot of the mechanics that a SaaS...

It's a pass. It's podcast as a service. I like that. That is a great one. I think that will stick, a pass. Write that down so we can use it in our marketing copy. Is it the P-A-A-S out there already, or is it a different version? No, that's the one. 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 it. Very soon. I'm excited about this specific feature myself because whenever I do have that ChangeLog 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 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 GoTime or I just listened to the changelog. Why do I get all these? And we just don't have, now we finally can say, hey, 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 were here. So we're looking at pull request 516,

trace GitHub actionsions 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 in GitHub Actions,

we can see that. You can see step by step each thing. So if you 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 whether 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 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 you 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 by default we can change this to say show me the workflows for the last 14 days what do we see what what do we see something that stands out just in these two graphs duration got higher on the 19th ish yes yeah 11 minutes exactly why did this workflow take 11 minutes that's exactly it like things like like why did why did this workflow take 11 minutes that's exactly it like things like why did 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,ub 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 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 Phoenix Framework, which is what changelog.com runs on. And he, again, he is our type of person for sure. He tinkered for one afternoon. He took Elixir, Flame flame and fly and introduced world page speed dot fly dot dev may 8th 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 changelog.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 changelog.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 would be running speed tests

for a website from all these places. This is really cool. So what do we see? Germany's a bit slow. Hong Kong's a little slow. Just to, again, add more detail, changelog.com, when it loads on this headless browser that is running in Frankfurt in a data center,

a flight data center, took 1,400 milliseconds to load. That's a bit slow. So I'm wondering if we 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 1,400 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 this should be really quick because well kind of quick right because 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 where the changelog application is. 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 much slower. I thought this was interesting. I like how this is 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 news y combinator compare it's slow right 850 milliseconds yeah so it's way smaller too is changelog yeah it is is chang 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 52 kilobyte page that's tiny. I know right? So what's going on there? It's 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? Man, Google is slow. Google.com,? I have to check myself, right? What? Man, Google is slow. Google.com, 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.

I was like, this is like Gearheart's HyperPing service, basically. Yeah. But right there, the browser. Yeah.

So, Sydney's especially slowing for Google. 2,000 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. So from a fly node near Sydney, right? That's how it works? It runs like in a data center near Sydney, right? Is that how it works? It runs like in a data center around Sydney, yeah. 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 can try HTTPS explicitly. Well, I just noticed that it doesn't do that when you just type in like changel.con, the domain. It's not defaulting to secure.

I know that we have a redirect. Yeah, we do. Well, I could 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 pick 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? 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 that was just magical.

You can stack trace essentially where in the bottleneck of GitHub Actions deploy, a deploy fails. That to me is like super magical to have that kind of visibility. But the same kind of visibility into page speed, especially if we care so much about it, because I think we do. 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 supersized? Is that what they know? Maybe. I don't know. Tokyo, it's again like 900. Tokyo is like the smallest one. And in Brazil, it's large again, but it's faster.

And then in Chile, it's large and fast. They have different payloads based on where you are to a large degree in terms of data transfer. I'm wondering if they're serving the cookie notification. You know that? Like when you load Google for the first time, you have to accept some cookies. Maybe that has something to do with it.

I don't know. I don't know if that would double the size of the page, but yeah. Yeah, but I'm wondering how does bunny.changelog fare? Is it still a thing? You still have that there? It's still a thing. Yeah, it's still running.

Okay. You can check it out. A little faster. Yeah. It's 300 milliseconds, 400 milliseconds. It's doing pretty good, I think. I think this has been the fastest one so far. Cool. So, Chris, we- Why do think this 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.

He has a plan, Gerhard. It's happening. What's happening? I agree to quote Gerhard. And Gerhard was saying on the last Kaizen, I like the idea of having this 20-lined varnish config that we deploy around the world. And it's like, look at our CDN, guys.

Pipe dream. Yes, pipe dream. You got there? Did you get there? It's so simple that it can do exactly what we want it to do and nothing more. But I understand that it's a pipe dream. I'm still quoting Jared. I understand it's a pipe 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 pipe dream. Not a pipe dream. I like that title.

So if you introduce pipedream.com, it's not that. Okay, so if you make this mistake, that's an honest mistake. pipedream.com, it's not that. Okay, so if you make this mistake, that's an honest mistake. Pipedream.com is a thing. Hang on, there you go. Pipedream.com is a thing. I didn't even know. Oh, wow, it's actually like a developer service. Yeah, yeah, yeah.

Connect APIs, AI. There you go. I thought this was going to be the first AI of the show. Well, they have to put that in the hero. This thing has almost 8,500 stars on GitHub. This is like a legit deal. 8,000, yeah. 8,500, yeah. This is a, so yeah, it has a video and all.

This is not what you built. No, this is not it. This is not it. All right, well, then get off this page. Okay, so you just need to do pipetree changelog.com. Okay. You can load it. You can try it. You can load it. And I'm going to share something else while you 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 while you look at it okay okay very excited 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 the last for best cool okay can you see my my 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's 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. this is not the first demo. There was another one. Back in January. Back in January, yes. When you guys ran into problems.

Yes, exactly, with James. This is you and James Rosen? Yes, the video is out. Let's build a CDN. 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 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- Yeah, 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 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 magic of fly to scale it around the world. It will run in 16 regions. Yes. Yes, you approve. I like this. I like where this is going. So let's scale approve. I like this. I approve. So let's scale it. I like this.

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. 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. It does be about that. Plus or minus, 10 bucks. So let's do that again and let's see what happened 369 and what do you see there x cash miss so this actually was served very close to where i am

right but it 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 oha 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 anchors, it's beautiful, there's bars, there's green, there 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 the slowest

one was 300 milliseconds 300 milliseconds yes you will always have some outliers and the fastest ones are all also eight milliseconds i think we can ignore them because you always get one which is super fast so you always get one which is super slow sure 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 not a pipe dream it's not a pipe dream i don't think it is i want to see that i'm i'm beyond tickled i want to see the code for this i want to see my 20 lines of varnish we're getting. 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. We're getting there. So

the next thing we have to compare this to changelog.com, right? We're doing the same measurement. We measured pipe dream and we, we went to pipetream.changelog.com to see the webpage, right? How, how it loads. So now we're doing the same speed test same moha 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 it was 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.

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-dos, 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. Wow, big guess. 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 of it. So that's PipeDream. It's a Varnish config that's deployed to 16 fly machines around the world. Yep. That when you go to pipedream.chainsaw.com, it is a proxy for chainsaw.com. It's actually Varnish. It's a Varnish configuration. Yeah. 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 do we ship it? Exactly. And it got down to, what was the milliseconds? In the sub-100s, right? Like 40-something? 38. Yeah, 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 Bonnie here.

So we're going to open another one. Let's change Google. Pipe dream. Change to.com. HTT. So we're going to open another one. Let's change Google. Pipedream. Change.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 the pipedream again. What do we see? 400 milliseconds, 500, 300, 300, 4, 4, 5, 7. If only, if only we could see this over time, right? So let's see, what do we see here?

So we see again, hyperpain. 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 a challenge, right? Because there's still

bandwidth costs. Yeah, there's other things you have to do. Oh, yes. I'm just being excited. 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 that 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 a Varnish term, right? Which is the backend 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 we obviously 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 notes. 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 buy it or should we build it?

That's what 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 officially, it does make sense to pursue because it's the itch, right? It's the scratching our own itch back to the really simple CDN idea we came up with four Kaizens ago. I don't know.

That's kind of what this is. Can there be a version of this that doesn't have to be not so much that the Cloudflare fronts or fastlies 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 can 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 think the purging thing is probably the most pertinent thing because we do purge frequently enough when we have misses or issues or whatever.

That's a frequent feature. Otherwise, it's what nodes and regions matter to us. Can we monitor their speed and fastness? 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 do we pay for it? I think if we can figure out how do 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 handle the static content, because that's where the bulk of the bandwidth is. Even if we handle the static content, 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 flat out IO conversation, but it's not twice as much.

We're not talking twice as much. We're talking 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 I can't remember. I 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 there's two sides to this coin from my perspective.

One, it's super cool. So, BA. 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 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 of what we already got seems like the first one's yes because like it is awesome and the third one's a possibility because it's within the range and the middle one is probably one to maybe spitball 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 we're 50% there.

It took me some number of hours. We're not 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 the 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.change.com alone,

which has the bulk of the bandwidth and has the logging issues and has all 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, 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 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 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.changel.com alone, then we learn a lot more.

We build something that's continually cool. 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 afforded. Yeah. The way I think of this is simple.

And we come back full circle to where we started. Fastly is a B-day. How do you pronounce it again? B-day. There you go. B there you go it squirts it remembers it does the water the whole thing okay okay keep going i'm tracking it's an algae pipe dream is a wet wipe it's simple it's practical take it Same 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. 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 4th 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. Garrett, pull some screenshots if you can. Will do. 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, you know, 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 changelog.com slash literally plus plus or words plus plus right don't both redirect your plus plus the words and they both work spell it out you can use the characters yeah either either way get there right it is better it's better 10 bucks a month 100 bucks a year and uh see what we're gonna do with this cdn'sN this saga I mean it's like it never ends there's subtle jabs in the middle of shows there's finales at the end there's pipe dreams I mean 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 YouTube channel. So follow us

there at youtube.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 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 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 Adam and Jerry at some other rental. Have a great weekend. Share the Change Log with your friends who might dig it. And we'll talk to you again real soon.