Kaizen! Three wise men?

Welcome to Changelog and Friends, a weekly talk show about the joy of missing out. Big thanks, as always, to our partners at Fly, the public cloud built for developers who ship. Learn all about it at fly.io. Okay, let's Kaizen. Well, before the show, I'm here with Jasmine Casas from Sentry. Jasmine, I know that session replay is one of those features that just once you use it, it becomes the way. How widely adopted is session replay for Sentry?

I can't share specific numbers, but it is highly adopted in terms of, if you look at the whole feature set of Sentry, replay is highly adopted. I think what's really important to us is Sentry supports over 100 languages and frameworks. That also means mobile. So I think it's important for us to cater to all sorts of developers. We can do that by opening up replay from not just web, but going to mobile. I think that's the most important needle to move.

So I know one of the things that developers waste so much time on is reproducing some sort of user interface error or some sort of user flow error. And now there is session replay. To me, it really does seem like the killer feature for Sentry.

Absolutely. That's a sentiment shared by a lot of our customers. And we've even doubled down on that workflow because today, if you just get a link to an issue alert in Sentry, an issue alert, for example, in Slack or whatever integration that you use, as soon as you open that issue alert, we've embedded the replay video at the time of the error. So then it just becomes part of the troubleshooting process. It's no longer an add on. It's just one of the steps that you do, just like you would review a stack trace. Our users would just also review the replay video. It's embedded right there on the issues page.

Okay. Sentry is always shipping, always helping developers ship with confidence. That's what they do. Check out their launch week details in the link in the show notes. And of course, check out Session Replay's new addition, Mobile Replay, in the link in the show notes as well. And here's the best part. If you want to try Sentry, you can do so today with $100 off the team plan, totally free for you to try out for you and your team.

Use the code CHANGELOG, go to sentry.io, again, sentry.io.

Well Gerhard, did you create a slideshow for us?

I did. Do you want to see it?

I absolutely want to see it.

All right. Let me screen share it.

This is you kaizening our kaizen episodes with slideshows.

Of course. You have to have them. It just makes things so much more interesting. I haven't posted the last one, but I will do this time.

Okay.

See screen, window, boom, boom. There you go. Kaizen 17.

Oh, man. I feel like... Jeez, dude. It's a nice font.

What's that font? I'm not sure. Let me double check. I think this is the default one that the template has.

I like the one.

San Francisco. It's Inter. Inter. I-N-T-E-R.

Inter. Interesting. Okay. Inter is cool.

I've used that font. IA Presenter. IA Presenter. Been loving their stuff. IA Writer. Yeah, yeah. I've been using it for seven, eight years. So IA Presenter is...

It says IA Presenter.

Okay. Yeah. I love how they write about it and the whole idea behind it. So it's nice and simple, and I can knock these out so quickly.

Love it. Love it. I love your magic carpet ride of Kaizen.

Cool. Okay. Well, the big thing or the main thing should be the main thing. So I was thinking we should start with the main thing. If Adam is ready for it, I'm ready for it.

Always be ready. We're ready for it, Gerhard. Okay.

What's the main thing? Well, you tell us, Adam. I'm looking at you.

Oh, you're talking about CPU.fm and the change we're making.

Oh, yes.

This is good stuff. So there's a very famous person. His name is Newton, at least, Sir Isaac Newton. And he said to paraphrase him and to paraphrase a very awesome movie, humans, the only one they've found to move forward in life or to get somewhere is to leave something behind. And so as part of that idea and mantra, we have decided to change things in 2025 to focus solely on making this podcast you're listening to right now, the single best developer podcast experience. News on Monday, interviews on Wednesday, Fridays on the weekend or on Friday mostly. And that's going to be some fun stuff. So that's what we're doing. Some of our favorite shows are going away, transitioning, moving on, spin offing, continuations. But that's what we're doing. What do you think? Was this a shock to you?

It makes sense. It was. I was surprised when it when, you know, we talked about it, honestly, I could see it coming. I mean, it just makes sense. It resonates with how I like to approach things. And it just fits with that mentality. Double down on the thing that you enjoy doing the most. And the thing that, you know, I think makes you special. Because this is what makes you special, I think.

On that note, though, we really enjoyed producing Go Time GS party, Ship It and Practically I like we loved the people, the shows like Jared will tell you because he hasn't spoken about it yet, at least in this podcast. We really deliberated over this for a while. I would say so long so that it's probably at least a year or more of considering how to change to get to where we're trying to go. And it was a struggle because it's not easy to retire something, move on from something to give someone or an entire world of audience bad news. And that's not something that you do quickly or lightly. You do it with intention and precision. And even then, even when you do it precisely and with precision and intentionality, it's still hard to get it right, you know, and so there's no really good version. Some will be upset. And that's that's how it goes, I guess. But our intention is to love well and to love the hosts and panels we worked with for many years very well. And to ease this process of them either spinning off something to do their own thing, which almost every show has some version of continuation, actually, every every one of them does. JS Party is has a new show called Dysfunctional.fm, Nick, K-Ball, Amy, Go Time has done a spinoff called Fall Through.fm, Chris, Ian and more extended friends from our existing podcast family of people who listen, Ship It has its own spinoff called F-A-F-O.fm, folk around and find out. Cool. Love that. Justin and Autumn. And then practically they're keeping their name because Chris and Daniel were unique. We've been working with them for many years, probably the longest running show and independently they had no other panelists.

Just those two.

Yeah, just those two for many years. And you know, it's just a it's a labor of love to produce these shows. It's a treadmill in the media world and we've been doing this for 15 years. It's not like we've been doing this for a day. You know, we've got some some reps under our belt. You know, we're swole, so to speak, in the podcast world. It's funny to say out loud, but we've been doing this for a while. And I think just having a chance to sort of pause for a moment and think about, OK, to produce a really good podcast that has a video first production workflow, to do that even for this show that produces three shows a week, we have no more bandwidth to do it. We would only be able to do that if we scale the team or if we just didn't do it. And we haven't done it for many years. You go on YouTube and you have clips only, which is great. But people have been asking us for years, can I get the full show on YouTube, the full video show? And I think we've there's opportunity cost there not doing it. We've missed out on audience growth, connection, you know, more in-depth content. Et cetera. And the only way to get there really is to make a major change as we did. But I think CPU.FM is a big vision, burgeoning new idea that hasn't doesn't have the full fruition yet, but has a big vision. So I think what we'll do to support these shows and to support this change all podcast universe, what's called CPU.FM, I think it has big opportunity. And so I think if people continue to trust us, join CPU.FM, let us support them. But they produce their own shows. We're no longer part of the media machine they are where we're helping them ship shows

daily, weekly. That's a tough one. It's arduous.

Yeah, I think that the end result of this is a very real possibility that this change while it effectively takes away shows in the short term. I think it actually might result in more better developer pods down the road because we had reached our capacity. And for many years we've turned down ideas and opportunities because we are just maxed out. I mean, how many times has a listener requested a podcast from us about Rust? Probably a hundred, maybe slightly less, but many, many, many times. And I hate that, I don't hate it, but like I have an internal anxiety about that request because it's like, I just knew I couldn't do it. We couldn't do it under our current structure. Now there was another option. Like we could grow our business, we could grow our team. We could build out that way. And I think a large part of life is knowing what you want. And I've lived long enough to know that I didn't want to do that. I don't think Adam wanted to do that. And so we just, that wasn't an option for us just because we just don't want that to be our life. And so the other option is either stay at capacity, five shows a week, technically it's like seven shows a week because the change log is three episodes a week and live that life and make those shows. And we did that for a long time and that was a totally legit route or double down on the main thing, let a few of the things that we love go and see if their love returns to us tenfold. Now that's what the corny saying about, if you love something, let it go, right? Encourage the people who have been making those shows with us to make same or similar or new shows that we could support them, but independently as their own thing. So they could have full ownership, they could have equity and we can all podcast together and work together and collaborate. And so I'm very excited about where it's going to go. Obviously in the short term, it's on the bitter end of bittersweet, especially for me. I mean, speaking very personally, JS party is like one of my favorite things. I've grown very fond of that podcast and those people and what we do together and go time very similar. I'm not on go time on a regular basis. I do show up from time to time, but like I'm a regular on JS party. And so that is just emotionally, it's just a very hard thing to stop. I'm very excited that Nick and cable and Amy are going to continue podcasting together. And then I have a standing offer to join their show whenever I want and hang out because I just love the shows that we made together and the times that we spent. So it's been a hard decision. It's been a long time coming for us. Obviously we don't talk about our indecisions publicly. We talk about our decisions, but we've been toiling over this change. Like Adam said, probably for a year, we almost did it a year ago, honestly, but we didn't. And now we're doing it. Sometimes you just got to pull the bandaid off, you know, and it's hard, but it feels right. And I'm excited about January because I think it's going to breed some new life into our show, into these other shows. And yeah, those are my initial thoughts on it.

Embracing change. If we could use the title again, I think we should. Because it fits it really, really well. Change happens whether we like it or not. This way we are in control, gaining something, losing something, you know, just all part of the game. You have to go back to the roots, doing the things that you love. First of all, knowing what that thing is, it's really hard because the world is a busy, noisy place. And there's always the imposter syndrome. We know how well that works. And we also know there's always the grass is greener on the other side.

And the FOMO.

It's not exactly. But the joy of missing out, right? The JOMO.

I really like that take. The JOMO.

The JOMO. Exactly. This could be it. Another baby title idea. The joy of missing out.

That's the first time I've heard that.

Oh, really?

That's brand new to me right to this moment.

Yeah. I think I've heard it first from DHH.

Oh, really?

Yeah. The joy of missing out in the context of remote work.

Of course he would make that up.

I'm sure he did. I don't know. The point is, it's about leaving slack in the system, focusing on the things that you know you enjoy and you're good at, sharpening that axe, and doing the best work that you can, leaving room to do that. And that's really hard and really challenging. But it's worth it. Because at the end of it, you look back 10 years from now, 20 years from now, and you realize how rich your experience was because you made the choice. It all starts with a choice. And it's not like you're stopping everything, right? You're finding another home. You're just like, there's like a whole like new twist and new perspective. It's the next evolution in the changelog universe. And I like that.

Yeah. You know, just to laser focus on one specific thing that I've personally had angst with is that we've had a great opportunity to help many brands reach developers over the years. Like obviously we're sponsored. Most podcasts are. Any podcast that's sustainable or being sustained is usually sponsored in some way, shape or form. You find any podcast out there. The biggest ones out there. Even Joe Rogan. He's sponsored. You know, we've had this ceiling of ability to help folks because we have limited shows. I really believe that Jared and I are pretty good tastemakers. And I think the idea with CPU is pretty cool. And we want to help more of those brands reach more developers. And we had a ceiling. I would often tell folks, because I'm a big, big helper when I reach, when I work with these different brands and I know that I'm like, I can only help you this well with the shows I command under our belt. And I think that Jared and I are two people. We have limited bandwidth. We add folks onto our team as necessary over the years to support us in producing podcasts. But at some point, like we had a limit and now we have so much more opportunity to help more brands reach more developers through CPU. So I think that's the coolest thing for me. I think being able to expand that to, you know, 10 or 15 podcasts with an index, with a single subscribe point for many really awesome developer podcasts that join this, I would say somewhat of a movement in a way, world-class developer podcasts, like that's a cool thing in my opinion. And we have this big vision that is literally at the spark, you know, of the moment at cp.fm. And I have, and we have a big vision for it. And I think it'd be good for us, good for, like Jared said, the awesome shows that will come from it. But then more importantly, like helping developer brands reach developers is really, really hard. The ones who have a good story, they're just so new. They have, they need great awareness, but they're just so, you know, brand new in that story. They have almost nowhere to easily go to execute, to get the word out of who they are, what they do. And like that self-serving way to me is one cool way that I see a much more bigger opportunity

for them and for us and for the shows that get supported from it.

One other point I like to make on this, and then I'd love to get into your work Gerhard, is that we had built out this portfolio of shows that we love and listeners love and hosts love, and it was all good. There was no real struggle or there's no, it was just like, of course there's the work of scheduling and rescheduling and sponsors and this happens and that happens and we got to get the thing out. Like that's all just work, right? Of producing podcasts. But I got to a point where we're doing these seven shows a week, and this is relevant to Kaizen, that I didn't have any bandwidth to actually experiment. I was writing, I almost said this the other day, Adam, we had Chris Coyier and Dave Ruppert on the show last week, on Friends last week, and we were talking about my desire to stay in the trenches and be actively developing. I just have not been writing enough software lately. I want to build stuff more and I just didn't have any room to breathe. And so I literally would just do Kaizen-driven development, which is every two and a half months, right? Like, please don't look at my commit messages between the last, you probably already did, between the last Kaizen and now. It's not very much. I just don't have the bandwidth and that's not good for our show. That's not good for me personally. That's not what I want to be doing. I want to build stuff more and I'm so excited as we do laser focus on the changelog, as we do take these productions off of our weekly calendar, even though the shows will exist in spirit as other people's productions, I got room to breathe. I got room to code. I can block an entire day and just be like, I'm going to build something today. And that I think is a huge benefit to this particular change, which brings us to the work you've been doing because I haven't done Jack squat, Gerhard, hopefully even Kaizen-ing because we've just been producing podcasts. If not, we don't have a show if not.

So I really get that too at a very deep level because that was at the root of the Shippet

show.

I was doing it on hold. That was exactly it. Room to breathe, room to experiment, room to do other things, room to do things differently. That's how it started and it's coming up to a year and it still feels right. And you're right being like, it takes a certain amount of adulthood and the strength of character to know that that's what's happening. And I'm really glad that you're in this point. It's an amazing point. Very important one, essential for what's to come next. It's a catalyst. So it's the beginning of something amazing and I'm so excited to be a friend of this amazing journey. Very, very excited.

You are a friend. You're part of it. You've been a part of it for a long time.

Thank you very much.

And we're excited to keep you as a part of this as we grow and change. We didn't highlight that much though in the, in our post, like there's nothing changing about Kaizen. Like Kaizen is now embedded into the changelog podcast itself. Just to be super, super clear, it was implicit. It will be more explicit here. There's nothing changing about Kaizen. In fact, I think it won't get more frequent. I think it might get better because I think Jared, to your point, I think you and I might have more time to do more development to make us less like Gerhard, what did you make so that we can have a podcast and some iteration and some change.

So to everyone listening, I want you to know that this conversation has been thought out weeks in advance. You're at the baseline. It only gets better from here. Yeah. So stick with us. This was the big announcement. This was the important stuff. And now we're going to have some fun. Okay. And trust me, the last thing, have you tried to keep it a secret for a while? I think I've succeeded and it's going to be amazing.

Oh, man.

So sit down. You want to sit down for this one.

Okay. I'm more anxious now than I was. Is it early Christmas? It is.

Early Christmas. I love it. It is actually.

Yes. So things are coming together. So Gerhard has some presents for us, I think. Okay. One.

Oh, just one.

Gerhard, you know the philosophy. You have two of everything.

Come on, man. Well, there is another one. But anyway, see, I can't hide this from you. You know me too well.

Can we just skip to the end? Can we just not do this middle part? This is why we need to have video podcasts too, because you listen to Nadi all these years, have not seen the extreme laughter we've had on this podcast in particular. That's true. As a video. Like you may have seen it in clips, but you haven't seen the full length.

And you can hear Gerhard's joy in his voice, but you can see it in his face even more. Oh yeah.

All right. Gerhard, I'm so excited for whatever it is.

By the way, this little part was for Jason, the editor. I met him for the first time when we recorded the last Ship It episode.

Oh, nice.

And that was very nice. So this laughter was for you, Jason.

Okay, there you go.

Right. So this bit you may edit, but I knew this is going to be fun. And I thought about you as you were going through the show. Oh, nice. Hopefully it won't be just my laughter. It'll be everyone's laughter because you'll go a bit crazy. Okay. But in a good, tasteful way. Okay.

This is not telling Jason what to do. Make sure it's good and tasteful, Jason.

Exactly. No wet wipes or nothing like that. Okay, so let's start. All right. So in the last Kaizen, you were thinking, Gerhard, of getting a brand new Mac. That's true. To try out the newly introduced Just Contribute. That's true. And you were saying that you've been waiting for a reason to upgrade.

Right.

It was Black Friday. Christmas is coming.

True.

And I hear that the M4 is all the rage these days.

I've heard so much good.

So good. Yeah. I've resisted hardcore.

But yes. I almost went out yesterday and to the Apple store.com, whatever the website is, and priced one out. My trepidation is like, we really maxed out these Macs that we're currently using. Like my current MacBook Pro, which is a 2021 M1 Macs, it was the first M, but it was the maxed CPU. First of all, it's still very good. And so that makes it hard to buy something brand new. It is the 2021, but it's 64 gigs of RAM. It's got a massive like multi terabyte hard drive. Like it was basically like, go to the configurator and hit the max on everything besides the size. It is a 14 inch, not the 16 inch. So aside from the screen size, it's just maxed out. And so I hate to go buy one new that has less specs than this one. But when I go max out the new one again, I'm like, can I justify this because my one's working pretty well, you know? And so, or I could go downstream and like, do I really need all that storage? Do I, do I really need all the RAM? And so that's where I just like close tab and move on for a little while. So no, I do not have a new Mac, but gosh, I want one.

Did you try just contribute? Because that was the point.

I'm already a contributor, Gerhard. So I didn't really have, I've used just, but I have not tried just contribute. So no, I failed you in that way.

Adam.

No, sir.

Sorry. Oh man. Come on. Now, in all honesty, I know that a few listeners have tried. I forget who exactly it was. There was someone that mentioned that a lot of work has gone into it. Do you remember that, Gerhard? It was one of the comments, maybe. I forget his name. That's all I know. It was, I want to say it was Adam, but no, it wasn't Adam. It was someone else. Anyway, it was someone. I'm not going to look for it now, but it's there. People can try it, and we'll be building on top of that. Also, in the last Kaizen, and by the way, there's going to be video. This will work well. I was mentioning that I'll be talking at TalosCon about how I took my home lab into production, and so that happened. Something special about that was that it was a recorded talk by myself. I did the editing. I had multiple cameras, and it's out on YouTube, so you can check it out.

Very cool.

The one thing that was one of my favorite moments about this talk is me showing off the actual home lab. So the home lab was a Latte Panda Sigma, and the size, for comparison, it's exactly as big as an iPhone Max, iPhone Pro Max. So you have an iPhone-sized home lab, which is insanely powerful. You can run Kubernetes on it, 16 cores, DDR5, multi-terabyte NVMe drives, and it can serve 300 billion requests per minute. Sorry, per month. Sorry, that would be crazy. No. 300 billion. I was like, wait a second. No, no, no, per month. Sorry, requests per month. So a lot of, like, many, many billions requests per month. Anyway, we may link to the talk for you to go and check out.

Oh, absolutely.

So the one thing that was really interesting about this specific device is that it has an Intel CPU. And I know that Intel now has not been doing that great this year, but they do have video sync, which means they can do video transcoding really, really well. So they have GPUs that can do video transcoding. This one has an Intel Iris Xe graphics, which means they can do video transcoding amazingly well. So let's take the internet level plus one.

Always.

And for this, both of you, you'll need to take out your browsers. And you will need to go to jellyfin.makeitwork.tv.

Are you going to share with us your home theater setup or what?

No.

OK. I'm there.

You're there. So enter your GitHub username. And for the password, by the way, if you're listening, this will change. The password is kaizen17.

I'm in.

OK, what do you see? Tell us.

My media, I'm in the Jellyfin home page. I see drafts. And recently added in drafts, I see some vertical video thumbnails and a horizontal video thumbnail.

Excellent. Click on one. Click on the drafts.

OK.

And pick the 4K one, 2160.

Full 2160p. I see a loading spinner.

Great. It's running on my shelf, by the way. There is a CDN. But it's running on my shelf, the home lab. And the video is being served from that home lab instance. So this is home lab taken further. What is this video? This video is the last conversation that we had with James and Matt about building out the Pydream CDN. This was August. It took me a while to edit the video. Did it load, by the way?

Yes, it loaded. I just had to pause it so I could listen to you talk. It's running smoothly, too.

Excellent. So this video is running off that latte panda sigma. It's being fronted by a CDN. So it's turtles. Turtles and turtles. And this is the content which I always imagined I would produce. Content that has the conversation part. And content that then we do screen sharing and we go deep. The content that you're looking at is about an hour, the whole thing, the whole hour. And it was edited down for about three hours. That was a long conversation. And it's still a draft. So it hasn't been published yet. But it's coming. So taking the home lab further, doing the CDN. In a way, it's the adventures, the CDN adventure. I think that's what's happening. And kaizening our home labs and kaizening the devices that we all love, whether it's an M4 or an Intel based home lab. So you're part of something special. Just like CPU.fm is special. And it's coming. It's not there yet. But there will be a little more things coming maybe just in time for Christmas. Series of videos that are, I'm thinking of them as movies for infrastructure nerds. And makeitwork.tv will be the place for this when it's done. Let's also makeitwork.fm, but makeitwork.fm is just for the conversations. Just like the audio part. So that's how this works.

Nice. Love it.

So changelog is very embedded in this. Because a lot of the experimentation that I do happens in the context of changelog. And then on top of that, take it further. Make the time to create the content that uses that. But obviously, there's so much more that happens. The editing, you have no idea how much it takes me to do the actual editing. That is my biggest issue. So I have an appreciation for video, 4K video done well, and sound and everything. For it to sound right, to look right, to the color grading. Just takes a while. DaVinci Resolve, I think I've been using that app more than my terminal in the last, I don't know, six months. I've been learning it. I've been, it's amazing. But anyway, back to Kaizen. Back to the Kaizen 17. So we talked about the CPU FM. We talked about the home lab. And we finally did it. The thing that we talked about for a while, Jared, right? Enable team members to replace changelog dev with a prod db dump. It's pull request 533. Did you try that?

Yes, sir.

Tell us about it.

It works.

Great.

That's what I care about. It was fast. It was seamless. It just worked. I think I did have to configure something the first time. I think you were making some changes to nvrc files. There's just been some environment variable things that I had to do the first time. But I can tell how you, the last time around, by using this just, is it a toolkit? Is it a library?

I would call it a CLI utility. It's like a make, it just improves on make, basically. If you've used make, that's what a command runner, some would say.

Right. So we'll just call it this CLI tool that you made the change easy, and now you're making the easy change. Call back to the previous episode, call back to, of course, Kent Beck's first make the change easy, warning this may be hard, then make the easy change. Classic quote from Kent Beck, because this was like a pretty easy change for you, it looked like, in terms of this particular one. Now you had some neon things to do, but you can tell us about the details of how it worked. The PR itself seemed pretty straightforward and small, and then it worked, so that was my experience.

Very nice. I'm very glad that you experienced it that way. I'm curious, when Adam tries it out, how well this works for him. The idea is that we wrap a bunch of commands that you would need to run locally, right? So for example, installing the neon CLI, so that you can control the neon. By the way, there's two. You can do it via NPM, or you can go and download the binary. The binary, the version, it's a slightly different one, so there's some inconsistencies in the CLI binary from neon, but this basically handles all of that. And what I thought would be easy, I thought this change would be easy, but actually there were quite a few rabbit holes that I had to go down on. One, for example, was how to download in the format which is compressed, right? Because you don't want to download many gigabytes locally, so how do you compress it automatically? And then, how do you handle extensions that exist on neon, they're installed on neon, but you don't have locally in your Postgres database? So there was that as well, so I had to uninstall an extension which was giving us metrics that you can do via SQL queries. So there are like a few things like that that I had to go through. But still, what it means is that this command, just restore devdb from prod, that's exactly how we call it, and you can look at the pull request. There's even a video which just shows how it works. It wraps all of that complexity, like all that know-how, you have to run this command and you have to pass this value. And the other thing is the credentials, they're pulled just in time from the 1Password vault, you don't have to remember them, and it orchestrates all of that. So the integration, I was really happy with it, how it worked, and it feels like an easy thing to wrap your head around. There's nothing complex about what's, obviously there are a couple of niggles to sort out, but you don't see them when you use it. And you can even see the commands before they run, you can copy paste the commands, so everything runs locally. And I think this was the hard part before, because when we were using Dagger for this, that was running in containers, but you don't use containers, so we had to make that big change so that you would have this nice local experience, everything runs again, it doesn't need Docker, it doesn't need anything like that, it doesn't need Dagger, it's just commands, installing binaries, things like that. So I'm glad that you tried it, I'm glad that it's working, do you see yourself using this?

Yes. Immediately, yes. It's just so straightforward, I mean, all the things that you just said right now are things that I love. And so I'm way more likely to pick up this simple tool, especially following your example, than I was, honestly, even with the old Makefiles, which because of your expertise in Makefiles, I was perpetually lost. I've looked at the Just files, and they're just easier for me to grok. The fact that there's no containers, there's no Dagger, there's no things that I generally put in the black box of like Gerhard land, it just, for me, as a regular app developer, it's more approachable. And so I script stuff all the time. This is basically taking a script of mine that I would do and just have on my local machine to do all these steps, and it's formalizing it into a shared repository. I'm way more likely to follow that lead and create additional Just commands. And now I have time too, so I'm totally into this, Gerhard, one second.

Oh, I'm so happy, I'm so happy. That's a huge score.

What's up, friends? I'm here with Cal Carberry, co-founder and CTO at Coder.com. So Coder.com is a cloud development environment, a CDE, and you run all the clouds, AWS, Azure, GCP, you're on-prem, and you're no stranger to competition, right? The competition out there is well known, but what shocks you, what surprises you about the state of cloud development environments and how developers are leveraging them?

You know, it actually shocked me. The majority of our Go largest provision customers do not use containers with their development environments. They actually use VMs on like GCP, AWS, or some kind of mixture of them. One of the largest auto manufacturers, they have like a little bit over a thousand devs that use Coder every day, and they use a mixture of Azure, AWS, and GCP.

So I've used Docker, I've used VMs, but take me into the technical details. What is it that's different between a VM and running something in Docker?

Kind of like all existing solutions, like kind of our competitors in the market, all really have a container-based approach where you build like a Docker container and developers work inside of that. And it faces a couple of limitations, because you know, Adam, like if, you know, on your machine right now, 100% you're not working inside of a Docker container doing this discussion, right? It's just very different. So there's a lot of software expectations that actually don't really work inside of a container. An example is a customer of ours is Square,

and they do stuff with a payment terminal. And so they need essentially like hardware accelerated Android.

That is just really finicky to get working in a container. You totally can pass dev KVM into a container and get hardware accelerated virtualization, but it's a little trickier and a little more janky. And so they'd rather just be like, no, the simple thing is give everyone a VM. There's no point to change the way that we work in entirety to do some weird virtualization jank. It just makes more sense to give them a VM that we know works.

Well, it might be time to consider a cloud development environment. And open source is awesome. And Coder is fully open source. You can go to coder.com, get a demo or try it right now, or even start a 30 day trial of Coder Enterprise. Once again, coder.com, that's C-O-D-E-R.com, coder.com.

The next one was enabling team members. The next pull request, pull request 534, was basically building on top of this. And it just enables team members to run dev with a neon db branch. So this was a rework of what we had before. That's why it removed more lines than it added, but basically built on top of the same just approach. Did you try this command, Jared?

No.

No, okay. Will you ever have an interest to try this command?

So this creates a new branch on neon.

Not just that, it also configures your app. It starts your app with that neon branch. So there's no more manual. It's like one command and it will run everything. It will create the branch and then it will configure your app to use the branch. There's no more manual digging around and you can believe this.

Yeah, potentially. I do like to develop against production as a branch. I prefer to have it pulled down locally. So I think I would probably opt for the other one that you just created, which is why this one wasn't as exciting to me and I didn't even try it. But would this also do syncing between those two branches? Because that's my bugaboo, is you do a branch off of prod. Then you're developing against the branch and then you want fresh data. And so I already have a command that gets me the fresh data locally, but if I didn't, then I go to the neon deal and I go find the place in the UI where I hit sync to main or whatever and I don't like that step. So if this could do that, I mean, maybe it'd be a second command that just, I'm sure it's available via the CLI somehow.

Yeah, I haven't looked into that. It does make sense. It does make sense to add it, by the way. And even if the CLI doesn't support it, maybe there's a curl request that we can do to the API to get this synced. But that makes sense.

Yeah, because that's really what I want is I want the freshens every time. And so it would be nice to have something like this.

Right, so the freshens ones, to get the freshen ones, which is a great idea, by the way, the first command will take longer because it has to pull down the entire database. And that takes a while. And then it has to load the entire database. It basically removes what you have locally and then just records everything. So that can take up to five minutes depending on internet connection, a bunch of things.

Yeah, I experienced that. And so this would be faster.

This would be fast, yes.

Generally, when it's time for me to develop, I issue that command. I go get a fresh cup of coffee. I come back and I'm ready to rock. So like, you're gonna do it once a week, maybe. It doesn't bug me to have the five minutes. If I was doing more experimenting and changing and stuff, I think having these immediate branches, like without any sort, I would still have a little trepidation that like maybe I'm pointing at the wrong thing.

That's why the command now handles all of that so that you don't have to worry did I set the correct environment variables? Is everything correct? And because everything happens inside of the command, once it gets to a point, like we had, for example, Adam's case, where, you know, sometimes it fails and then you don't like what state am I in? This command tends to be self-contained. What that means is that once it gets to a certain point, you're safe, you're sure it will continue and it will finish and it will do the right thing and it's all embedded in the actual command. Now, this command, when you're connected to a remote database, it can be slightly slower. So for me, for example, I preferred downloading all the data locally and having all of that locally because it felt snappier. And even though we, the query planner, we warm up the query planner so that, you know, things are cached, we do a couple of things like that, it still feels slower. It still is slower because it has to do all those round trips, right? And they're all remote. They're all remote calls to this remote database. So I think the choices between paying the penalty once, five minutes, three minutes, depending on your internet connection to load all the data and then you know you have the latest, or pay a little bit of penalty every time you do you load the page because it may take, I don't know, a second slower sometimes, depending on how many queries you're running. So both options are there. I think, knowing Adam, I think he would prefer the second option so that he's connected against a remote database and I think he would prefer the first option. So we have a mix of both.

I think that's probably accurate.

Yeah. But we'll make sure that this works for Adam as well. Not in this context, but as a followup for sure. Cool. Well, the next thing which improved for us, and this was great to see, was the all-in Zulip approach. Zulip, how do you pronounce it? Zulip?

Zulip. Pretty much, that's how we pronounce it.

Great.

Adam pronounces it Zooli.

Zooli?

That's right. Like hooli. He thinks they should drop the P. Like hooli, exactly.

See?

Okay. Kindred spirits. That's Adam's idea. Drop the P, call it Zooli.

That's right. So I think at this point, everyone basically migrated from our Slack to Zooli. Who are Zooli? Everyone's there. The conversations are there. I won't call it Zulip, Zulip, Zulip. It's just a joke. So everyone migrated to Zulip. How does it work?

Amazing. It's awesome. I think it's easier to track and follow better than Slack. When I go back to Slack now, I feel like I'm in some sort of archaic way of communicating, which is just like, just throw it at the wall. And if you see it, cool. You can't compartmentalize conversations. Threading is obviously there, but it's not the same as Zulip. It's threaded conversations for teams is what their mantra is, basically. The one key thing I think that makes Zulip different in terms of how you interact with it as a user to communicate is that everything is based on a topic. So if you're starting something new, you're beginning a new topic, which can be to some degree daunting. Because you think, well, if I want to say something, I must have a place to say it. And if there's no place to say it, then you feel like, oh, I got to create it. Is it that important? Maybe that's what stops you from communicating. I don't fully disagree with that sentiment. I kind of wish there was a merger of the worlds where you have a single place in Zulip that is non-threaded, where it's just like this is where everything goes. But then I can kind of feel the angst against that, because if your principle is communication must correspond with a topic, and that's your way, I can understand why they've sort of harkened into their ways to not do that. But as a user, I kind of want the Slack world in a way where it's just like everything goes where it can go, like a main channel, for example, and then also still have the topic world. But topic-based, inside of our Zulip we have the different podcasts, there are episodes, you can comment on a Kaizen 17, for example. It's really compartmentalized, which I like a lot, and those threads are long-lived. We've got this WordPress drama thread that was not started by me or Jared, it was started by the community, and it's still being active today. Whereas in Slack, that conversation would have just died and got reborn, and the context of prior conversations isn't there. So you have this community, keep it together, long-run conversations that can be potentially months, maybe even years, and that's just not equally as possible in Slack. You can do it, it's just not present so easily in the UI. That's why I love Bazel.

Yeah. It did take me a while to get used to the idea that everything is a thread, but then once you make that switch, you realize, actually, this allows me to be more focused. I can just pick a thread and I'm there, that's the context, I can see it everywhere, so I can see everything that was discussed in that thread. So that's really cool. Also, having a thread per episode, I think that's a great idea. I cannot remember how many times there was a comment on an episode on the Changelog website, which I just couldn't find. I couldn't find how do I get to the comments on an episode now, so much easier.

Yeah, I think that's been really nice, especially for podcasts where they are consumed, not just asynchronously, but massively asynchronously, where there's people who are living off the fire hose and they listen to the episode when you drop it, and then there's people who are three months behind perpetually, and then there's people who are back catalog dwellers, where they're listening back through the catalog and they may listen to it years later. Well, there was never a place where all those people could easily find, here's where that discussion is. And so the thing that I've heard the most and which I've enjoyed is people's ability to hop back into an older episode and either strike that conversation back up or even just read it, what people had to say in the time between it shipping and you listening to it. So that's really cool. I do have, after living, and anytime you live somewhere for a while, you see all the warts, I'm starting to have a little bit of the, not buyer's remorse, but just like Zulip wart finding adventures, if I might call it that. The mobile app leaves a lot to be desired. I know they are rewriting it right now in Flutter, and so they're working on that. There's all kinds of little UI things that just bother me about Zulip, and the URLs, I'm a URL guy. I can't believe some of the URLs these folks put together, because it's basically, it's an SPA, and everything is like, go read the URLs. They're just not pretty. And when you're trying to deep link into stuff, I don't know, that matters to me. It offends my sensibilities. When you're deep linking into something and you're like, look at this URL, I got to go give somebody. Stuff like that, just not minor nitpicks, but it's definitely better. It's better than Slack in many ways. And while we are all in pretty much on using Zulip, we haven't done any sort of finalization in terms of like the blog post I was going to write, probably still will. Like we haven't closed our Slack. Probably can't at the moment. There's still conversations happening there, mostly in private team chats, some with collaborators who we don't want to just ask them to move to Zulip, because it's just kind of odd and strange to be like, by the way, from now on, if you want to communicate with us, switch to Zulip.

We must come over here.

So we are living in a little bit of a...

Blue-green, I would call it long blue-green.

Yeah, it's a blue-green deployment. Yeah, exactly. And there's lots of green on this side of the grass, but it's not entirely there yet.

Yeah. Do you see us shutting down Slack at some point?

Sure hope so. We certainly can, especially for just like the public discussions of like, there's no, like Slack is cut off at this point in terms of joining. Like the website is all, you join the community, you get invited to Zulip. You can't get a Slack invite unless you go inside of Slack and invite somebody. And so it's like essentially cut off from the world. And there's no conversations happening there in the public at all. Every once in a while, somebody will say something, mostly they're spammers. Our new episodes are still posting there. I haven't quite made that change yet. I figured we'd do some sort of more big announcement first and like encourage people who are still in Slack one last time to come over to Zulip. But we do have a lot of team chats and private chats that are ongoing and used that we haven't quite gotten cut over to. And some of them, like I said, are with like folks from partner podcasts and stuff. I don't know. We haven't decided if we're gonna actually like close the Slack, but we would like to.

Yes. It would be nice to just have, not have to have it as an option so that you miss conversations or have to track one more place.

I think it's, the sad part about our Slack is that it is a free Slack. And so that means after the rolling time schedule they have, conversations just go away. And that's not cool. I just really hope that Slack goes away for us. I love Slack. You know, my real hope, I suppose, maybe if I rewind it prior to Zulip, I have two hopes. I would love Slack to support communities better and support non-enterprise, not so that they can, I think there's just so many people who have Slack embedded into their world. It's not going away. I'm part of other Slack. So Slack isn't gonna go away for me. It might go away for Changelog, but it's not gonna go away for me as an individual human being.

Same.

I would love it if Slack supported communities better. And that way, places like Changelog could have had some sort of relationship that didn't have to be free. We don't wanna be freeloaders to Slack. We would love to pay, but we have 7,000 people in Maine at one point, not all of them active, but if we had to pay for everybody in there, OMG, we would go broke, right? We can get it sponsored maybe, but then it's like, well, does that really add value to a sponsor to support that Slack channel? Maybe. I mean, there might be ways we could do it, but it would be kind of maybe icky to enable that. So I just would love Slack to revisit the idea of the ubiquity and embeddedness that they have with developers and the community aspect that just doesn't get to foster without paying large sums of money. Find a different business model that supports those folks. I think you'd change some things. Second, I think that Zillip has so much potential. And I say that not in a negative way in the fact that they're not reaching it, but they have so much potential to reach lots of people. I've had to say to people, we don't use Slack anymore. We use Zillip, and they're like, what is that? That is an absolute shame. That's what that is, because Zillip is so cool. It's open source. There's an amazing team behind it. They have an iOS app, an Android app, a web app, but for the faults that Jared mentioned, I think they're held back by some beliefs they have that have just held them back. But then again, they're held back may be perception for me and not them. They're held back as like, no, we're doing exactly what we want to do. We're reaching communities, and they're supporting us. We fit perfectly in their world in terms of how we as a community use Zillip. I just think they could more thoroughly compete with Slack if they changed a couple things. I don't know how to say that really in this podcast, but there's opportunity there. There's hidden potential they can seize. And I hope they do it. My two hopes are Slack support better communities, or support communities better, and Zillip to reach their full potential.

Yeah. By the way, just as you solved your problem with 1Password.

Nice.

I solved my problem with who posted that just contribute worked well. That was Matt Johnson. Oh my gosh. It was in Zillip. Zillip. It was Kaizen just do it. That was the thread. I found it. And he wrote, Matt Johnson wrote, just an install and just install worked pretty cool. I then ran just contribute and wow, yeah, that does a lot. It worked though. So just contribute worked for Matt Johnson, September, 2024. So now I know how to find it. It was in Zillip all along. Nice. Cool. Okay. Well, one thing which I also liked is how, when you post an episode, there's a mark down for all the chapters. And that was Jared's magic. So even though he didn't do a lot, which I think he did, by the way, he's just being modest. This was the one thing that he did. And I love that improvement.

Thank you. This was one of these moments where you're just like, it's markdown. That's easy. Markdown has tables. I wonder if they support tables. Yes, Zillip supports markdown tables. That's pretty easy. Why not add chapters? And the cool thing about it was I had a little bit of concern that it would be too long if you do that. However, Zillip will take long messages and collapse them by default when you first look at the thread. And so if you don't want to look at the chapters, it doesn't bug you at all. You want to get straight to the other people's conversation. So that was nice to see. And yeah, one of the cool things about having our database, our admin, our backend as the central source of truth for our chapters versus in the MP3 file or in the RSS feed is that we can basically emit those in different places that make sense. And this seems like a place that really makes sense because if you're just hanging out in Zillip and you're not sure if you want to listen to an episode because it's not really your bag of tricks, but maybe we talked about something you're interested in somewhere in the middle, you could just scan the chapters real quick and see if anything catches your eye. I thought about linking up each chapter directly to the start time over on the website. So you can actually click on them and listen from there. I didn't quite get that far. I'm not sure if that's, would you love that?

I would love that, honestly. Like once I've seen these chapters, that was the point like, wow, this, like this all of a sudden made Zillip 10 times more useful for me than Slack ever was. Nice. Because now I can see the episodes, I can comment on the episodes, same interface, and I can see the topics, right? These chapters, super useful. The one thing which I was missing is where's the link to click on the chapters? So this would be so amazing.

That was like on my to do next list because it's just easy for, I've already done most of the hard work. It's just a matter of making those links clickable. And so maybe what I needed was a little encouragement. I'm happy to add that as an easy Kaizen.

Would love that.

I would concur and plus one that because that would make me click a chapter start time easily because it would be clickable for one. And I want to now.

I want to, but I can't.

And I cannot do that. I will say that when we go to a video first world and we're bifurcated temporarily while we have interviews, this is sort of somewhat in the weeds. We may roll out one show as video first and the next second. It might make that integration slightly more harder, but you know, because it might link to need to link to YouTube, for example, to a timestamp versus to our site as a timestamp.

But you still need to write like the timestamps in YouTube. So you have to generate the chapters ahead of time. You just take texts, they convert them automatically.

So yeah. Hence the workflow challenges we've talked about

in the new era for the changeable podcast universe is this.

The question becomes, do we have one artifact?

Yeah.

That is identical in both platforms or do you have a slightly different show on YouTube than you do in the audio? Because of reasons. And so we're still in the throes of figuring all that out. But I think once we figure all that out, adjusting the stuff for the chapters won't be too hard because we already had done all the hard work.

I did try both approaches. And I do find that YouTube is a different medium. And I think to get them to get the best out of it, you have to cater to the audience that's on YouTube. And that audience prefers the content to be a bit punchier, a bit like more to the point, right? Like don't lose the audience because they have certain expectations. And we're not even talking shorts. Shorts is completely different.

Sure.

Right? So this is just when you put a video on YouTube. Yes, great. But I think the transitions, they need to be a bit quicker than you would have in a conversation.

Yeah. I mean, even just the way that we do a pre-roll ad in our podcast, we come up with like the intro, the voiceover, and then a pre-roll ad. And it's like, is a YouTube video with a pre-roll ad at the beginning going to get action over there? I don't think the people on YouTube want that. Do we just cut straight to the interview? So there's like a lot of those kind of, and then all of a sudden now you have basically two shows you're doing for the price of one. And so, yeah, we're still figuring all that out.

Yeah, two cuts. It's like a director trying to do like, oh, here's the extended cut and the theatrical and the producer's version of it all in the same release. Like, no, that doesn't happen, right? The extended cut always comes later. It's usually like, oh, that was much better. Or in the case of Ridley Scott, that was much worse because he likes his original cuts better first.

Sometimes the extended cuts are much worse because it's the director being entirely up their own butt with their love of their story. And it's like, no, the cut was really good, actually. Your editors are excellent. Other times, the extended cut's awesome. So it is hit or miss, but for sure, for sure.

I am on the 10th conversation, editing the 10th conversation right now, the one that you saw in drafts. And the conclusion which I reached is that audio has to be separate, right? You focus on a listener, not a watcher. Then you focus on the YouTube audience, that they want something quick, they want something free, they want something entertaining. And then you have to focus and cater to the real nerd. They want to see the whole thing. They want to see like a great cut, but they want to see, they want to immerse themselves in the story. That is not your YouTuber. That is, I don't think that's your listener because especially if you have some video, which is like screen sharing, that is different. And that's more engaging. That just basically ups the ante and ups the story and takes it to a whole new level. So those three audiences are very different. And I end up with three types of content, same conversation, three types of content, catering to the audience. And again, we're not even talking shorts or Instagram or TikTok, which just requires another approach. Speaking of improvements, there's one more that I noticed and I was so happy to see Jared do that. Notifications, deploy notifications in Zeelep. That was so cool.

Yay, I forgot I did that.

How was it building that? Like how was that building it?

I don't even remember, to be honest. In fact, when I saw those code deploys, I thought, did Gerhard do that or did I do that? That's how much it's been a bit of a whirlwind around here. Easy, I guess. I do remember once you have basically the Zeelep API, like their stuff is so simple. That's one of the things I like about them. There's no OAuth, there's no like craziness. It's just like, look, go ahead and generate a token. And then throw that token in a header. And all the requests that you have that token in the header, we're gonna let you do what you wanna do. Now there are some fine grain controls beyond that, but they just start from the basic place. And so that made me getting Zeelep abilities inside our app, like 30 lines of code, you know, for the module that changelog.zeelep module, which invites people and posts stuff. And once you can post stuff, then you're just basically, you're halfway there. Now, how does this work? Honestly, I don't recall. Is this going through GitHub actions?

It is, yeah. So from GitHub actions.

Okay, so this probably isn't even my code doing this. It's probably just a GitHub action I installed.

Yeah, I think-

All right, how'd I do it, Gerhard? How'd I do it?

Let me open it up because it's been a while since I looked at that. And there's no pull request, there's code, so I have to go look at that. That's me, that's me, no pull request, yes. And it's spread across a couple of actually commits, so-

That's also me, yeah.

So you're making- This is how I roll. That's how you roll, that's how you roll.

It is. So- I cannot be myself, you know? PR is actually aligned with the idea of topics in Zulep. Like, you know, to get code into a repo, your way is PR-driven, topic-driven.

Yeah, the reason why we do it that way, or the reason why I prefer to do it that way is because it provides an interface to a conversation. Right, so if people want to check it out, if people want to, for example, they just want to see the video of how the thing works, well, you go there. It also allows me to capture a lot more content, like how do you put a video in a commit message? I mean, you could put the URL, but then where do you host the video? With the pull request, you can put all this context there to capture why I did it, and it's useful for me as well. So all the previous pull requests that we mentioned, the 5.3.3, the 5.3.4, there is a section which captures how does that thing work? And that's me making sure that I run it myself on a different machine to make sure that the thing works, and how does it work? And sometimes, more often than not, I find issues and I fix them. It's just a more, I don't know, wholesome way of approaching something, and I enjoy it. I think it's a more professional way as well. However, I still do commits. Commits have their place, so I'm not dissing them. I'm saying, all I'm saying is different approaches and different contexts and different ways of sharing that information.

I think your way is definitely better. I think the difference between you and I is you want to have a conversation about this stuff, and I just want to get stuff done, and so I just do stuff. And then I'm like, well, Gerhard, I'll figure out how to talk about it on Kaizen.

Yeah, that's it, yeah.

So I offshore my conversations, which reminds me, how did I do this? How did I accomplish this? Did you find it? I think I must have just installed a GitHub Action there.

You do use a GitHub Action. This is, I'm looking at, in our changelog repository, GitHub Workflows, the dagger on namespace, that's the one that I'm looking at, and it's line, right now, 68. Announce, deploy in Kaizen Zulip. And you're using the Zulip GitHub Action, Zulip send message v1. You have an API key, you have the email, organization URL, two type topic content. I think the content was the interesting one because you had to trim the Git sha, you had to use a short sha. I've seen a couple of commits where you were trying to fix-

I was tweaking it.

Exactly, yeah, yeah.

All right, so yeah, it's just basically, you use an existing GitHub Action, and you tweak it to your liking. And so it's even easier than writing your own API client, which I did for all the other integrations. But yeah, this one was so easy, I forgot.

Yeah, well, it looks good, it works well. I was very happy to see this, and it's in the Kaizen channel. It's exactly where it needs to be. Code deploys, it's all there, so you can go and check it out. That's very nice. So the one thing which I had to do as a follow-up, pull request 536, right? We have two of everything. We are running the primary deploys through namespace. They run Dagger for us, and they run the actual, the CI and CD parts as well. But we also run GitHub as a fallback. So what we wanted to do is announce deploys in Zloop as well on the GitHub Runners. So all I did was just basically copy what you've done, Jared, and put it there. The fact that I copied it makes me think that they should be refactored, they should be simplified in some way. There's quite a lot of configuration. So it's something for my list. However, we discussed in the last Kaizen the namespace runners and how much will they cost us per month.

All right.

So now the numbers are in, and we get to pick. So option A, it cost 50, 50? Yeah, 40 cents. Typing this up, 40 cents. So 0.4 dollars. That's option one. Option, no, no, no. I went too far. I went too far, hang on. I'm doing this like as a live edit, and I don't want to.

He's live editing his slideshow.

Cool, all right. B is one dollar, and C is two dollars. How much do you think it costs us per month?

40 cents.

A, correct. It was exactly 54 cents.

Wait a second, you just said 40 cents, and then you said correct, and then you said it was 54 cents.

Well, out of these options, option A is closest to the reality. I didn't give you the right number. It was, I didn't want to make it 50.

It'd be too obvious, I guess.

Yes, too obvious, exactly, yes. So maybe I could have done like 0.5.

It was, yeah. That would have been more sense.

There you go. 0.5, so I fixed it.

So half a buck.

Half a buck, yes.

For a month of namespace.so. Concurrent runners, that's what they're offering, right?

It's a fast GitHub actions runner with caching built in, and a bunch of features like, for example, a nice UI which shows you how long your builds are taking, how much CPU they're using, memory using, so just get more insights into what's happening when the builds run.

Right, not a sponsor, but they certainly should be.

I think so.

They're on my list.

I really think so.

Put that on your list, Adam. Okay, cool. 2025, name.some, I'm coming for you. So thanks for spotting us, Gerhard. This is on your credit card, right?

It is, yes. 0.5 dollars.

So just invoice us.

Yeah, for the first month. We'll see how the next month goes. The pay as you go thing is a basic, but yeah. Pull request 535, this is also a follow-up. We improved on the ZU lip auth integration, so.

This is my fault, too.

Yeah, you remembered the old way, where we just basically configure environment variables like secrets in our fly.io app, and we don't want to do that. The reason why we don't want to do that is because we have the one password CLI integration, which means that when the app boots, just in time, it loads all the secrets. So that's what the 535 is.

Yeah, I just forgot about that, so I just did the old-fashioned way, and so thanks for fixing it.

That's why we have to have everything. You want a backup. You want someone to back you up. Yeah, cool.

What's up, friends? I love my 8 sleep. Check them out, 8sleep.com. I've never slept better. And you know I love biohacking. I love sleep science. And this is all about sleep science mixed with AI to keep you at your best while you sleep. This technology is pushing the boundaries of what's possible in our bedrooms. Let me tell you about 8 sleep and their cutting-edge Pod4 Ultra. So what exactly is the Pod? Imagine a high-tech mattress cover that you can easily add to any bed, but this isn't just any cover. It's packed with sensors, heating, and cooling elements, and it's all controlled by sophisticated AI algorithms. It's like having a sleep lab, a smart thermostat, and a personal sleep coach all rolled into one single device. And the Pod uses a network of sensors to track a wide array of biometrics while you sleep. It tracks sleep stages, heart rate variability, respiratory rate, temperature, and more. And the really cool part is this. It does all this without you having to wear any devices. The accuracy of this thing rivals what you would get in a professional sleep lab. Now, let me tell you about my personal favorite thing. Autopilot recap. Every day, my 8 sleep tells me what my autopilot did for me to help me sleep better at night. Here's what it said last night. Last night, autopilot made adjustments to boost your REM sleep by 62%. Wow, 62%. That means that it updated and changed my temperature to cool, to warm, and helped me fine tune exactly where I wanted to be with precision temperature control to get to that maximum REM sleep. And sleep is the most important function we do every single day. As you can probably tell, I'm a massive fan of my 8 sleep, and I think you should get one. So go to 8sleep.com slash changelog, and right now they have an awesome deal for Black Friday going from November 11th through December 14th. The discount code changelog will get you up to $600 off the Pod4 Ultra when you bundle it. Again, the code to use is changelog, and that's from November 11th through December 14th. Once again, that's 8sleep.com slash changelog. I know you'll love it. I sleep on this thing every night, and I absolutely love it. It's a game changer, and it's gonna change your game. Once again, 8sleep.com slash changelog. And also by our friends over at Wix, I've got just 30 seconds to tell you about Wix Studio, the web platform for freelancers, agencies, and enterprises. So here are a few things you can do in 30 seconds or less on Studio. Number one, integrate, extend, and write custom scripts in a VS Code-based IDE. Two, leverage zero setup dev, test, and production environments. Three, ship faster with an AI code assistant. And four, work with Wix, Headless APIs on any tech stack. Wix Studio is for devs who build websites, sell apps, go headless, or manage clients. Well, my time is up, but the list keeps going on. Step into Wix Studio and see for yourself. Go to wix.com slash studio. Once again, wix.com slash studio.

All right, we have a bit of more time, so now we're going to go into one of my favorite topics that has become one of my favorite topics, and that's the pipe dream. What is a pipe dream? Tell us, Jared.

The pipe dream is a world, a future world.

In a world.

In which, ooh, Adam should tell us. He says the actual trailer boys. In which you can just run your own little CDN with a varnish config deployed around the world on fly.io machines, and you don't need to have a CDN anymore because you've built your own CDN, and it makes sense, and you can just open source it and share it with the world, and everything's simple, and you got 20 lines of varnish, maybe 50, maybe 100 lines, maybe 200. You have to update us on the lines of varnish.

Still 60, we're still on 60. That has not changed.

That's pipe dream.

That's pipe dream. Single purpose, single tenant CDN for changelog.com. It runs varnish cache, the open source one on fly.io.

So we've been working towards this, you've been building it. Last time around, I remember saying, can ICANN has test suite or something like that?

Yeah, pretty much.

And I know I looked at a test suite pull request, so I think I know where this is going.

Yeah, so the issue that Jared opened in the true open source spirit is wire up a test harness. That's right. Because I said, create an issue, open source for the win. That's right. You did it.

You know, I opened that issue after listening to Kaizen 16 and hearing it back, and you telling me to open an issue, and I was like, oh, I never did. So there I went, did I even quoted myself? And I quoted you in the issue.

Yeah, very nice. You did, that was amazing. So that was issue two. Issue two. And that was a pull request, pull request three, which adds tests. Yes. So what is interesting about this? Well, we're using Just, same as before, one tool. We seem to be standardizing on that. Yeah. It runs Just test. And when we run it, it creates a report. Why does it create a report? It uses this amazing tool. Many have heard of it. Hurl, H-U-R-L. Not sure if it's the best name, but anyway, we didn't pick it. Hurl.dev. And hurl.dev is orange open source. It's a CLI that, actually it's more than a CLI, but you interact with it through a CLI, which allows you to write tests and assertions about HTTP requests. So the focus is on testing HTTP endpoints. And it's written in Rust, which means it's really fast. It has a very simple DSL. You put it in .hurl files. And what does it look like? Well, let's have a look at this files changed. So we're going to look at files changed. There's a workflow which runs it. And it's just Just test. That's it. And when it comes to the hurl file, I've put it in test, by the way. There's the Just file. We'll scroll past that. Let's look at this one. Test admin.hurl. We get the host admin. We repeat it twice so that we can confirm the caching behavior. We expect the HTTP status code to be 302. And we say we want HTTP two. You can specify this in the file when you do like your configuration. And then you can write a bunch of assertions. In this case, we make sure that the response comes back in a second, by a thousand milliseconds in this case. We check that the header, the location header, sends us back to homepage, right? Because we're not authenticated. We also check that there's an xvarnish header because that means this request has been served by varnish. We are looking at the age, the age header, which should be zero because they should never be stored from cache. We look at cache status just to double check. And the miss, the cache status header should contain, in this case, hits zero and should also always contain miss. All this very nicely laid in a way that I think is easy to understand. And the fact that we can do repeat two, that's all we have to do to make sure the request gets run twice, which I think is really nice.

Yeah, so this is like a hurl specific DSL, which is text-based. And as I said in your pull request, seems super simple and easy to use. So I'm excited about that.

So this is pull request three on the pipe dream. And again, there's a video. How does this work? So I'm just going to play through it. There's no sound. But the thing which I wanted to go to is this report, which is really cool. So after you run the test, you can have a look at the output, which shows you exactly the requests, how they happened, what headers were sent, how did this behave, which I think is really cool. Did you try running this locally, Jared?

I watched your video. I didn't try running it.

Excellent, so the video works. And you get a nice waterfall to see how much the different parts of the request take. I think super useful.

So my question that I had after this, which I didn't ask yet, I was saving it, was obviously you run the thing, you get the report. But I assume the thing also has some sort of automated one or zero at the end of it, whether or not your tests passed without the report, right? The report's an additional thing. It's not like the output.

That is correct, yes. That is correct. So the report is separate. So the report is separate from whether the test was successful or not. And right now, this commit has failed. So this test on main has failed. So we see the failure. And the failure is that string edge grace hitsdale should not contain string stale, and it does. And also the age, like how long this has been cached for, we expect it to be less than 60, but it's been 67. So the system doesn't seem to behave the way we thought it would.

So this is testing not the varnished config specifically. This is testing the actual running nodes. Like this is the thing in production that it's testing, right?

Yes, that's it.

Okay, so it's almost like a integration test.

It is an integration test, yes.

How would you use it for development then?

Right, so this is the big thing which is currently is missing. It's not testing the configuration that is local. It's testing the deployed configuration.

I see, that's what I was just asking about. Yeah, because what I want to do is TD these changes.

Exactly, so for that, we need to put more stuff which spins up varnish locally. And then the question is, should the local varnish hit changelog the origin? Or should we also spin up an origin?

Are you asking me that?

Are you saying? We are going through this to see because here's the questions that we need to-

I couldn't tell if that's a rhetorical question or not.

No, no, here's the question that we need to answer so that we know how do we want to continue developing this. Because based on what we choose, there's almost like different trade-offs and different levels of how hard this is going to be. So do we, for example, want to run the entire changelog app locally? And if we do, then we need the database as well, which we can do, it's not a problem. And then we put varnish in front, which is the one that we develop, right? Just in time loaded with the varnish config. And then we run the test, right? So we need almost like four things to be running locally to be able to test everything, how the entire system fits together.

My desire would be to have my changes and additions to the pipe dream config, aka varnish, tested to assure that what I'm changing actually affects its way upstream or downstream, whichever way you want to look at it. I do not care in this context, whether the upstream or the downstream actually work correctly. In fact, I would like to be able to mock them in different ways. Like what if the app doesn't respond the way we expect to? I would like to mock that response from the app because the app's interactions and stuff is all tested elsewhere. And then our other upstreams is like Cloudflare R2. And so like that's outside of our control, right? So we don't want to test that that thing's working as it should. So I think we just want to keep it isolated to pipe dream and not like spin up an entire working system with nodes around the world and stuff like that. Okay. Does that answer your question?

It does answer my question. Yes, that's exactly what I was thinking. I just want to double check if you're thinking about it the same way. And it seems that you are, right? We only care about the configuration and pipe dream itself and how it interacts with origins, different origins in this case. Right. That, I mean, to begin with, we can just point it to those origins so that won't change. But what will change is that we are testing the thing that is being developed, the local thing. We're not testing the thing which is being deployed. Because the reason why I wanted to obviously test the local thing is, well, is my change going to work before I push this out?

Absolutely. And we could even take those origins responses and do something like a VCR and have those be played back.

Yes, yes.

And then we avoid production altogether.

VCR.

Remember VCR?

Yeah, exactly. For people that don't know Ruby are not coming from that world, like the moment you said that, like, of course VCR and the cassettes and damn it, I had to recreate them so many times.

Right, right, right.

But yeah, I remember that, yeah. It's a Ruby gem which basically allows HTTP requests to be recorded and replayed so that you don't make the real requests.

That's right. And for those people who are even less old, originally VCR was a tape-based medium in which you could record and play back television. The OG VCR. Yeah.

I hated those movies because the quality was so bad. And like the more you watched it, the worse it would get. The worse it would get because yeah, the media would degrade. So yeah, luckily we don't have that problem anymore.

Plus my original Star Wars VCR, which was recorded off of television, it got recorded over like halfway through for like a basketball game or something. It's like, goodness gracious, man. I'm trying to watch Star Wars here. You know what's funny about VCR? It stands for Video Cassette Recorder. But you would use a VCR to play primarily, right? As a user.

You could do both.

For both. I know you can, but like generally, most people assimilate or think of the VCR as you put a cassette in and you play it, is all I'm trying to say. It's like the general usage is not so much the R part of it. It's the VCP, Video Cassette Player. I think what we learn here is separation of concerns is a good thing. Don't make the recorder and the player in the same exact medium. You're gonna record over my Star Wars.

But do you remember the safety mechanism that cassettes had? There was a latch. If the latch was on, you couldn't record over it.

Oh yes, the tab, yes. And you could just tape over it, remember? Physical little thing there. Oh gosh. The days. The days, man. The bad old days.

Okay, so this all makes sense. I think for this, what I would do, and again, that's why we're talking about this, I would introduce Dagger for this. The reason why I would do that is because I need to create containers quickly, programmatically. I need to create services, connect multiple containers together, and check that everything works in a programmatic way. And if we don't have that, we would need to have some sort of a container runtime to run all these things. So that's what I'm thinking here. Sounds good?

Sounds good. Cool, make it so.

So, we're almost at the end. This is what we have been building up. Let's see how this lands. So we talked a few name ideas in the last Kaizen for Pipe Dream.

Correct.

What do you remember as a name that stuck with us all?

Pipely.

Pipely? Pipely. Okay. That's right. So we threw around a couple of the main names.

Correct.

One that we liked, that we all liked. Let's look like a who is.

Oh gosh.

Who is. Who does who is. Do you remember the domain which we wanted?

No.

I don't. So it was pipe.li. Pipe.li. That was, I think that was already registered as far as. No, it's unavailable actually. We can't even register it.

Oh. For shame?

Yeah. I mean, it says it's already registered. There's no info. .li domains are difficult for various reasons. So what was the other TLD that we wanted? Tech. pipe.li.tech. Let's see if pipe.li.tech is available. No. Someone registered it. When did they register it? Let's see, what happens if you go to pipe.li.tech?

Oh gosh. Oh.

Somebody else.

Somebody else has the idea. A new CDN is born.

What do we see?

It looks like it. What?

What are we looking at?

Three. This is us? Get out of here. Are these, these are.

The three magi.

Oh goodness.

It's Christmas. New things get born. So a CDN is born.

The stars in the sky. The CDN has risen. I don't want to burst your bubble, Gerhard, but it wasn't three magi.

Three wise men?

Nah. What was it? Well, it was a group of wise men. There was three gifts given, and so people always think there was just three of them, but people don't read the account very closely. But this is cool looking. I actually thought of, like, these were Jedi at first, so I thought you were going, because that looks like a futuristic city out there.

Yep.

Certainly that's not Jerusalem or Bethlehem or anything in the story.

Looks like Dubai.

It does look like Dubai. So, you know, maybe a modern take, but hilarious. A new CDN is born. Pipely. Coming what? Coming on the 25th? Or what are you trying to do here?

Maybe. I don't know. So pipely.tech. So if you go to pipely.tech is the main, and it tells the whole story, right? So should we build a CDN? I can click on that.

Oh, cool.

That's us. That's us. Always three. That's interesting. So three seems to be the theme here. Always three. Not two, three. So we're going there.

Now there's three wise men. Is that what you're trying to say? I like it.

I think so. I think so. Comparing CDNs. That's as well with nice screenshots we have. So the whole story, the whole pipely story, which I really like. I like the name pipely. I'm sold on it.

You sold on pipely. Well, you bought it. Pipely.tech.

Yeah. It's a thing now.

That's the one that I remember. I like it. I'm so down. Like beyond so down.

Pipely's coined.

Can I share some behind the scene nuggets? Of course. This is fresh. I want a plot coming to you soon. Actually next Wednesday. So on Wednesday of this week, which is the week of, I guess the fourth. No, what was Monday? The second?

Monday was a second. Yeah, yeah.

Second. December second. It's December 6th. So on December 4th, I had a conversation with Kurt Mackey. And I think you know his name because he's the, one of the founders and CEO of Fly.io, which we know and love here. Obviously I love Fly.io so much. It's so cool. And during that conversation, cause we talked about Tigris and the Rebel Alliance. He said it out loud on the pod. So I thought it was secret. We talked deeply about the Rebel Alliance and all the things that he had envisioned for it. And he's not, I won't spoil it. Let's just say, that's not the point I'm trying to make. I said, go to this URL and tell me what you think about this. And I mentioned this pipe dream idea. And I had forgotten about Pipely until this moment. In terms of a name, I laughed so hard the last time he said it and I'm the one that said it. But, I already mentioned in the podcast. And so that conversation was focused around, you know, the pipe dream idea. And he looked at it, he's like, I love this. This is so cool. I can't believe you guys are doing this. So I'll just say that in the fact that Kurt is excited about this. And there is this idea of a Rebel Alliance, just saying. So we have support and a blessing and a fan.

Yeah. And a name.

And a name.

And a story.

And a domain.

And a domain, exactly.

Gosh, it really does begin with a name and a domain because you can have a good name. I was actually bummed. I was like, holy crap, somebody took pipely.tech who had this idea? That is so cool. Yeah.

You did. I just had the execution. Okay, that's cool. Let's go for it.

I love the creativity though. I love the idea that this might be Jedi, honestly. And this is a future city with this star out there.

The Rebel Alliance is born.

Yeah, I think this is just really, it plays in well. I like it a lot. I'm beyond excited. I don't know how much to share in this podcast, but I'm like beyond excited.

Well, I'm glad. This is a great way to begin something new. And I didn't know that you'll make room for this, but I think you just did. Without knowing that pipely would be a thing. Think about how we began and think where we're now.

To rewind the conversation back to the beginning, Jared says something to me. Jared and I don't see each other face-to-face too frequently, a couple of times a year. And it actually, I've said this on the air, I think I said this in face-to-face, but he said to me, he's like, Adam, when you tell me new ideas, I just almost immediately cancel them because we have no time to do anything. And I'm paraphrasing what you said, but the sentiment is roughly there, so correct me, Jared, if you want to. But it bummed me out, because I'm generally not so much the idea guy, but someone generating vision in some way, shape, or form. And when he said that, I also thought in my brain in the moment, gosh, I've stopped casting any sort of vision in my own brain because I'm tapped too. So anytime I have a new idea, I don't have any room to explore it because we're doing all the ideas we can, essentially. And I think, and I don't know where Jared's at with this, but I would so make room for, I think this certainly makes room for Pipely. And it's certainly the main thing because we need an amazing CDN. And I shared in that podcast with Kurt some of the challenges. Well, you know, Adam, that Fastly and Cloudflare and every CDN out there is not, it's not in their best interests to cache all of your content on all their pops across the globe forever. That's not in their best interest. There's cache misses, not because they can't cache it, because they don't want to. And so the CDN we build, that we wanna build, will always cache everything you need to across the globe. And it will only expire when you say this is expired. There will never be a cache miss in this world. And that, to me, is what a CDN is. And so if we can build that world, I think other people will like that world. And I think people don't need, and this is even Kurt concurring in this, I don't think everybody needs what these larger CDNs can offer or do offer, because they just offer so much, more than you need. So I think there's a lot of opportunity here, honestly.

I like it. I'm behind it.

I could tell.

I love it. As much time or as little time as I have, you know, little by little, step by step. I mean, this is honestly like mornings and evenings and weekends and all sorts of like, the time to the point doesn't even matter. As much time as I have, I enjoy doing this and on top of all the other things, and it's fun. And I can see the need. I can see me wanting to use this, me wanting to build this, and just, I honestly see this improving a bunch of things. And if it doesn't work out, it may not work out, the story's amazing. And at the end of the day, that's what people remember. We tried, we showed up every day, and let's see what happens.

We came, we saw, we dreamt. We pipe dreamt.

We pipe dreamt.

And we pipe leed. We pipe leed. Dot tech. The pipe piper. It would be like the three of us, the pipe pipers. Look at me.

So in all honesty, I think the reason why these magi, they are faceless, is because it can be many other people. I know that we had Matt Johnson help us. We had James A. Rosen help us. And how many people out there are doing something similar? Maybe they don't have time. Maybe they want to. They're thinking about it. Crazy groups of people that have an idea and just go for it. You know, it doesn't matter where it goes or how far it goes as long as you have fun with it. And yeah, don't take it too seriously, I suppose. It's not about the profit. It's not about like this VC funding or at least that's how I think of it. It's an idea that we should keep investing in because it's the right thing to do. And it's a great story to tell. And looking back 10 years from now, 20 years from now, you're like, wow, we were part of that.

On, I guess, a different note, how close are we to this pipe dream not being a pipe dream? How real and how quickly can this be truly real if it's not real?

So honestly, it just depends on how much time me personally can dedicate to this over the next coming months. That's what this comes down to.

I don't mean pipe with the company or anything like that. I mean like our usage of pipe dream. Our usage, okay. The thing becoming real for us as the first, in quotes, customer, if that's the thing. True usage, does it make sense? Can it scale for us? Is it truly DevEx usable, et cetera? And then I think everything else after that is just like comes natural if it makes sense.

So let's talk through the roadmap. We have it right in front of us. We've added tests. We know there's more that we need to do here, but the same number of VCR lines, so that's still there. The functionality hasn't changed. The feeds backends, the only reason why this is not done is because I wanted to do pipely.tech. I thought that was a cool idea. That's the only reason. I did part of it, by the way. This now works. It didn't used to work, the feed XML. Now this loads. We only had HTTPS, so I've taken small steps towards it, but it's not complete. The reason why we need HTTP and not HTTPS is because we're using the open source varnish, and that does not terminate TLS. So we can only connect to HTTP backends. That's something that we discovered the hard way. So this, in terms of configuration, we're talking a few hours to get it all done, lift it from our existing VCL and maybe do a few changes, because this already exists as VCL in our Fastly config. Then sending logs to Honeycomb, this again a day, roughly. It's just like I'm just basically making stuff up because I don't, only once you pick it up, you realize how much, like all the rabbit holes.

Well, we still have to determine if the way we send logs the Fastly way is the way of the future. We know that we like a lot about what that does, real time, et cetera. I'm assuming that's what you mean by that.

So it's more around making sure that we send logs to Honeycomb so that we can understand what's happening in the system. We want to keep the same structure as Fastly so that all the queries will work, so there'll be like no interruption of service or like no big changes. So that's why I mentioned this. We just need to have some way of sending all the request logs to Honeycomb. That's what I mean by this. We also need to send logs to S3. This is something that Jared mentioned last time when we talked about Pydream and the roadmap. So we need, for stats, we need to set, just like to keep the compatibility, right?

What about swapping out Tigers for that, or MinIO or Minio if we wanted to not S3 it? Is there any reason to not do that?

It doesn't matter where we send the logs as long as we send logs to an S3 compatible API.

Gotcha. Which I tried to switch over to R2, by the way, but I couldn't because of the way R2 implemented streaming versus the way S3 does and the way Fastly actually pushes over to that.

Interesting.

And so we could have been on R2 entirely, but we're actually in both now because our logs still go to S3 and everything else goes to R2. Now, we wouldn't have that problem inside Pydream necessarily. So it could be send logs to R2, but we wanna keep the exact same format so that our analytics stuff doesn't get rewritten.

Exactly, yeah. So once that's why we do like the first part, which seems a bit easier to just send the requests, it doesn't matter which way you do them, honestly, but this will ensure that the service behaves the way it should. And I think this is more valuable from a functionality perspective. Then, fairly hard to implement purge across all app instances. I say fairly hard. Oh, man, I can see me and Jared getting together here because we need to figure out how to purge these correctly and how to do this from the app. Right, so the application itself will know which are the pipe dream or pipe instances and will send these purge requests. And we're looking at the Fly.io machines like we're running the same network, we can discover them, we have DNS. So a lot of the building blocks are there, but this is where the application needs to come together with the actual CD and runtime, in this case, Fly.io, to implement this purge via OBAN and like how we do things. So we don't introduce a third or an extra service. And then adding the edge redirects. This is really easy because it's just basically adding more VCL config. Most of it is copy paste, maybe a few adjustments. So it's very feasible. And we're talking, I would say, maybe weeks of work in total, but weeks of work spread over a long period of time. That's what's hard. Like the time on my part, you know, have the time to actually go through all these things, but I can make this my focus. That is a possibility.

Where should we end this pod? Should we end it right here? Possibility of these Jedi wise dudes bringing to fruition the pipely dream?

Yeah, I think pipely is a good idea. New CDN is born. I mean, we can see the journey that we've been on, right? Since January. That's when he started talking about, it was like the first Kaizen.

This whole year, yeah.

So, you know, we have been taking all these small steps towards it. We were uncertain for a long time. You know, is this real? Should we really do this? Is this a good idea? So we weren't like all in to begin with. And I think that we are getting close to being all in. As in, let's go for this. Let's implement it. Let's see how it would work in practice. Like most of the problem space, I think we have discovered it. Like we know like what are like the big items, not the actual implementation. But this seems a lot more feasible and a lot more realistic than it was in January, for example, when it was just a question. And I think now it's not like we're building it. It's like we are, I would say, maybe a third way through, maybe a quarter through, something along those lines. And there's still challenges around, for example, like the TLS termination. That is a big one. And that means that we can only proxy or forward request the origins, they have to be HTTP. The backends, as Varnesh calls them, have to be HTTP. I think that's not a problem for us. It's not a problem in the context of Fly, because everything is running like we have a private network so all the endpoints are HTTP and they're private. No one can connect to them. So I think that makes sense. R2 can also be public, it's not a problem. And when it comes to pushing logs, that's the one thing which I don't know. But honestly, I don't see Varnesh being the thing which will push the logs anyways. What I would use that I've been using for years is vector.dev. Vector.dev is a great tool for sending logs and metrics or anything like that anywhere. Data.dev acquired them since I've been using them, but since I've been using vector. But it's all very simple and straightforward. And even to this day, I use it in the context, and we use it in the context of the dagger infrastructure. This is a very important component. Other teams are using it in their own infrastructures that we are collaborating with. So vector seems to be the piece to pick and the tool to use in this context. Again, written in Rust, super performant, nice CLI, has a lot of things. So I think the building blocks are getting clear, just a matter of going for it. New beginning, new year, I think that could be the focus.

Let's go for it, man.

Let's do it, right?

Let's do it.

So excited.

Good stuff, Gerhard, always a pleasure, man. So fun. I'm impressed, it is always a pleasure.

Make a great team, really do.

We do make a great team, we do great things together. And we've stood, you've been here, Gerhard, since the proverbial beginning, the new beginning, the latest era, not including this new one we're about to go on to, yeah, 2016.

2015.

And that really brings my heart a lot of joy, honestly. I like relationships that stand the test of time, really. Obviously, that's a good thing for relationships, but yeah, it brings me a lot of joy. That's all I'll say, I guess. I'm excited.

Likewise.

pipely.tech. We have it.

We have it.

It's real. A new CDN is born. Let's do it. Kaizen.

Kaizen.

Kaizen.

Oh my goodness. That was a fun Kaizen. Even though we had some serious talk up front, there were lots of laughs, lots of progress being made, of course, and lots of surprises. Gerhard always has something up his sleeve. By the way, I'm sure some of you are sad and or upset by our 2025 plans, and I totally get it. I've had my favorite podcasts and indie shows go away, so I know exactly how that feels. Hopefully, this'll be a net positive in the long run, and even if not, we've had a lot of fun all these years, haven't we? Next week on The Change Log, it's news on Monday, our final edition of the year, so I'm doing a roundup of all the code, pros, and pods that shaped 2024, and our interview on Wednesday is gonna be a banger. Mitchell Hashimoto joins us for a deep, deep dive on Ghostie, his new terminal emulator that's so good and shipping out to the public before the end of the year, and on Friday, our seventh annual State of the Log Spectacular. It's almost too late to get your voicemail in, but if you're listening to this on the 13th or maybe the 14th, go to changelog.fm slash S-O-T-L and leave us a message. It means a lot. One more thanks to our partners at Fly, to Breakmaster Cylinder, who's hard at work on our State of the Log voicemail remixes, and to each and every one of you for listening to our shows. We love that you choose to spend time with us each week. That's all for now. We'll talk to you again next time.

See the end of Change Logging Friends with Adam and Jared and some other random. We love that you loved it and stayed until the end, but now it's over, it's time to go. So you probably should be coding. You take your backlog, it's an ad problem, so why don't you go? No more listening to Change Logging. It's silicone, but honestly, that's off your list of twos, it's why don't you go listening to...