The Changelog: Software Development, Open Source - Kaizen! Three wise men? (Friends)

Episode Date: December 13, 2024

Gerhard is back for Kaizen 17! We discuss our CPU.fm changes in-depth, detail new Zulip / Neon integrations & put our Pipedream to the test. Oh, and a Gerhard surprise (of course)!

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 Cassis 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.

It 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 edition 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. We can listen to ChangeLogging Friends Adam and Jerry

People you know ChangeLogging Friends It's your favorite ever show Well Gerhard Did you create a slideshow for us? I did Do you want to see it? I absolutely want to see it

Alright Let me screen share it This is you Kaizen-ing 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 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 a 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's cool. I've used that font. I-A Presenter. I-A Presenter.

I've been loving their stuff. I-A Writer. I've been loving their stuff. IARiter. I've been using it for seven, eight years. So IAPresenter is... This is IAPresenter. Okay. Yeah. I love like how they write about it and like the whole idea behind it. So it's nice and simple and I can knock these out so quickly. Love it. Love it. Well, take us on a ride, Gerhard. You know, 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. And Isaac Newton. Sir Isaac Newton. And he said to go 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. 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 uh that's gonna be some fun stuff so that's what we're doing some of our favorite shows are going away transitioning moving on spinoffing 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, you know, 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. Yeah.

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 Online. 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 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. And so there's no really good version. Some will be upset. And that's how it goes, I guess. But our intention is to love well and to love the hosts and panelists we work 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, uh, has a new show called dysfunctional. Dot. FM,

Nick cable, Amy and go time has its own spinoff called fall through. Dot. FM, Chris, Ian and more extended friends from our existing podcast family of people who listen Ship It has its own spinoff called

FAFO.FM fork around and find out, cool, love that Justin and Autumn, and then Practically I they're keeping their name because Chris and Daniel are 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 probably the longest running show and independently they had no other

panelists it was just those two yeah just those two for many years and you know it's just uh it's a labor of love to produce these shows it's a 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 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, okay, 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 there's opportunity on YouTube, the full video show? And I think we've, there's opportunity costs. They're 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. That's what 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 it 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 cp.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 there's 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 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 just 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 GoTime, very similar. I'm not on GoTime on a regular basis. I do show up from time to time, but I'm a regular on JSParty. And so that is just emotionally, it's just a very hard thing to stop. I'm very excited that Nick and K-Ball and Amy are going to continue podcasting together and that 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 band-aid off. And it's hard. But it feels right. And I'm'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. Yeah. Because it fits it really really well yeah 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 the take the jomo the jomo exactly this could be it another baby title idea the joy of missing out that's first time I've heard that. Oh, really? Okay.

It's brand new to me right at 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, 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, a 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. 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 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, 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 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 of the moment at cpu.fm. And I have, and we have a big vision for it. And I think it'll 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 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'd 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. 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. And I was writing. I almost said this the other day.

Adam, we had Chris Coyier and Dave Rupert 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 was, I just have not been writing enough software lately. Like 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

Kaizenine, because we've just been producing podcasts. If not, we don't have a show, if not. So I really get that at a very deep level, because that was at the root of the Ship It show. Me putting 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 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 our post, like there's nothing changing about Kaizen. Like Kaizen is now embedded into the changelog podcast itself like just to be super super clear yeah it was implicit uh it will be more explicit here right there's nothing changing about kaizen

in fact i think it 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? Right. So that we can have a podcast. Right. 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. All right. Even more fun. Trust me, the last thing, I've been trying 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. Gerhard has some presents for us, I think. Okay. One.

Can we? Oh, just one. But it's great. I hope. Gerhard, you know the philosophy. Have two of everything. Come on, man. Okay, let's- One. Can we- Oh, just one. But it's great, I hope. Gerhard, you know the philosophy. 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 Naughty

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 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 yes oh yeah all right take us on the ride 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 so this bit you may edit but I knew this was going to be fun

and I thought about you as we were going through the show oh nice so hopefully it won't be just my laughter it'll be everyone's laughter because we'll go a bit crazy

okay but in a good tasteful way okay this is now telling Jason what to do make sure it's good and tasteful jason exactly no wet wipes nothing like that okay so let's start all right so in the last kaizen you're thinking jared of getting a brand new mac that's true 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, continue. I almost went out yesterday 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 M one max. Yeah.

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. contributed so no I failed you in that way Adam no sir sorry oh man no in all honesty I know that a few listeners have tried I forget um who exactly it was there was someone that mentioned that a lot of work has gone into it um do you remember that Jared was in 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 somewhere. 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 Homelab 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 okay so you have an iphone sizedab, 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. Okay. So a lot of like many, many billions requests per month. Anyway, we may link to the talk for you to go and check it out. Oh, sorry. Requests per month. Okay. So a lot of like many, many billions requests per month. Anyway, we may link to the talk for you to go and check it out. Oh, absolutely.

So the one thing that was really interesting about, or that's 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 nerdness level plus one. Always.

And for this, both of you, you'll need to take out your browsers. Okay. And you will need to go to jellyfin.makeitwork.tv. Are you going to share with us your home theater setup or what? No. Okay. 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. Okay. What do you see? Tell us. My media.

I'm in the Jellyfin homepage. 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. Okay. And pick the 4K one, 2160. Full 2160p.

Mm-hmm. 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 Homelab. And the video is being served from that Homelab instance. So this is Homelab taken further. What is this video?

This video is the last conversation that we had with James and Matt about building out a PipeDream CDN. This was August. It took me a while to edit the video did it load by the way yes 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 and 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 yeah and it's still a draft. So it hasn't been published yet, but it's coming. So taking the Homelab further, doing the CDN, in a way, it's the adventure. It's a CDN adventure. I think that's what's happening. And kaisening our Homelabs and kaisening the devices that we all love,

whether it's an M4 or an Intel-based Homelab. 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 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 make it work.fm but make it work.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 you know 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 like so much more that happens like the editing you have no idea how much it takes me to 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, it 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 CPUFM, we talked about the Homelab, 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. That'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 or 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. Right. If you've used make, that's what a command. It just improves on make basically. If you've used make that's what a command runner

some would say. 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 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 you know control to you and by the way there's two you can do like CLI so that you can control 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 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 you can look at the pull request there's even a video just shows how it works it wraps all that complexity like all that like 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 one password 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 an easy thing like to wrap your head around there's nothing complex about like what's like obviously like a couple of like niggles to sort out but you don't see them when you use it and you 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. 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 make files, which because of your expertise in make files, 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, like it's more approachable. And so I script stuff all the time. You know, 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 to,

so I'm totally into this, Gerhard. Very nice. 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 run 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 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 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 DevKVM 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 NeonDB 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. 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 would 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 to add it, by the way. And even if 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 it just reports 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 faster, yes. 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 for for you're gonna do it once a week maybe yeah 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 I would still have a little trepidation that 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 had, for example, Adam's case, where sometimes it fails, and then you don't know, 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 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 choice is

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 load the page because it may take i 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 you 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 follow-up 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 Zuli. Zuli. That's right. Like Hooli. He thinks I should drop the P. Like Hooli. Exactly.

Okay. Kindred spirits. That's Adam's idea. Drop the P. Call it Zuli. That's right. So I think at this point, everyone basically migrated from our Slack to Zuli or Zulip. Yeah. Everyone's there. The conversations are there. I won't call it Zulip to Zulip. Everyone's there.

The conversations are there. I won't call it 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 like 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. So so 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

like a single place in zulu that is non-threaded where it's just like this is where the everything goes then i can kind of feel the angst against that because like if your principle is it must communication must correspond with a topic in your that's your way I can understand why they've sort of hearkened 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 Arzolip, we have, you know, the different podcasts, their episodes, you can comment on a Kaizen 17, for example, you know, it's really compartmentalized, which I like a lot. And those threads are long lived. Like 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, 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 what I love about Zulu. Yeah.

It did take me a while to get used to the idea that everything is a thread. Yeah. But then once you make that switch, you 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. I cannot remember how many times there was a comment on an episode on the Change.org 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 like massively asynchronously,

where there's people who are like living off the fire hose and they listen to the episode when you drop it. And then there's people who are like three months behind perpetually. And then there's people who are like back catalog dwellers where they're like 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 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've got to give somebody. Stuff like that. Just 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 the blog post I was going to write. Probably still will. We haven't done any sort of finalization in terms of the blog post I was going to write. Probably still will. 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. You 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. Do you see us shutting down Slack at some point? Sure hope so.

We certainly can, especially for just the public discussions. Slack is cut off at this point in terms of joining. 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 essentially cut off from the world. 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 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 folks from partner podcasts and stuff. I don't know.

We haven't decided if we're going to actually close the Slack, but we would like to. Yes. It would be nice to just not have to have it as an option so that you miss conversations or have to track one more place. I think 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. My real hope, I suppose,

maybe if I rewinded prior to Zulu, 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 going to go away for me. It might go away for ChangeLog, but it's not going to 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 want to be freeloaders to Slack. We would love to pay, but we have 7,000 people in main at one point, not all of them active, but like 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 Zulip 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 Zulip. And they're like, what is that? That is an absolute shame. That's what that is.

Because Zulip 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 just, they're held back by some beliefs they have that have just held them back. But then again, their held back may be perception for me and not them. Their held back is like, no, we're doing exactly what we want to do. We're reaching communities and they're supporting us. Like we fit perfectly in their world in terms of how we as a community use Zulip. I just think there's, they could more thoroughly compete with Slack if they changed a couple of 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 communities better and Zulip to reach their full potential. Yeah. By the way, just as you solved your problem with 1Password, I solved my problem with who posted that Just Contribute worked well.

That was Matt Johnson. It was in Zulip. It was Kaizen, just do it. That was the thread. I found it. And he wrote, Matt Johnson wrote, Just and install and just install worked pretty cool.

I then ran Just Contribute and wow, 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 zulip all along nice cool okay well one thing which i also liked is how when you post an episode there's a markdown 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 uh 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, Zulip 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, Zulip 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, you know, 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 Zulip 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, like once I've seen these chapters, that was the point like, wow, this, like this all of a sudden made Zulip 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. 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 yeah I will say that when we go to a video first world and we're bifurcated temporarily while we have interview 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 yeah

they just take text they convert them automatically so yeah hence the workflow challenges we've talked about in the new era for the ChangeLog 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 yeah 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 this 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 you know action over there i don't think the people on youtube want that do we just cut straight to the interview there so there's like a lot of those kind of and then also now

you have basically two shows you're doing yeah 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 you know 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 really scott that was much worse because he likes his original cuts better first well sometimes the extended cuts are much worse because it's the director being like 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 they're saying it cuts awesome so it is 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 on 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's 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 ZLip. 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. Wow. Easy, I guess.

I do remember once you have basically the Zulip API, like their stuff is so simple. That's one of the things I like about them. There's no OAuth. There's no 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 going to let you do what you want to do. Now there are some fine-grained controls beyond that, but they just start from the basic place. And so that made me getting Zulip abilities inside our app, like 30 lines of code for the module that changelog.zulip module, which invites people and posts stuff. And once you can post stuff,

then you're just basically 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. Alright, 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, no pull request. And it's spread across a couple of actually commits. That's also me, yeah.

So you're right, this is how I roll. That's how you roll. It is. I can't not be myself, you know. PR is actually aligned with the idea of topics

in Zulip, 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 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 a pull request you can put all this context there to capture why did it and it's useful for me as well so all the previous pull requests that we mentioned the 533 the 534 there is a section which captures how does that thing work and that's me making sure that i ran 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 more professional way as well however i still do commits commits haveits have their place. So I'm not dissing them. I'm saying, all I'm saying is like 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. So I offshore my conversations, which reminds me, how did I do this? How did I accomplish this? How did you find it? I think I just, I must have just installed a GitHub action. You do use a GitHub action.

This is, I'm looking at, in our changelog repository, GitHub workflows, dagger on namespace, that's the one that I'm looking at. And itelog repository, GitHub workflows, 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, to type topic content. I think the content was the interesting one because you had to trim the git sha, you had to use like a short sha. I've seen a couple of commits where you were trying to fix

that integration. I was tweaking it. Exactly. Yeah. Alright, 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 CI and CD part 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 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, you know, 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. I'm typing this up, 40 cents. So $0.4. That's option one. Option, no, 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 live editing in a slideshow cool for those listening b is one dollar and c is two dollars how much do you think it cost 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 okay yes exactly yeah so maybe i could have done like 0.5. Yeah, that would have made more sense. There you go. 0.5, say, fixed it. So half a buck. Half a buck, yes. For a month of namespace.so.

Yeah. Concurrent runners, that's what they're offering, right? It's a faster GitHub Actions runner with caching built in and a bunch of features, like, for example, 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, named out. So I'm coming for you. Thanks for spotting us, Gerhard. This is on your credit card, right? It is, yes. $0.5. So, name that. So I'm coming for you. So thanks for spotting us, Gerhard. This is on your credit card, right?

It is, yes. $0.5. So just invoice us. For the first month. We'll see how the next month goes. The pay-as-you-go thing is amazing. But yeah. Pull request 535.

This was also a follow-up. We improved on the Zulip auth integration. This is my fault too. Yeah. You remembered like the old way or we just basically configure environment variables like secrets in our fly.io app and um 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 yeah which means that when the app boots just in time it loads 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 to back up. You want someone to back you up. Yeah. Cool. What's up friends? I love my 8sleep. 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 8sleep and their cutting edge Pod 4 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 eight 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 Plug4Ultra 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 love it. I sleep on this thing every night

and I absolutely love it. It's a game changer and it's going to 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 that has become one of my favorite topics and that's the pipe dream yes what is the pipe dream tell us jared the pipe dream is a world a future world in a world in which oh adam should tell us he has the actual trailer voice 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 no change that's pipe dream

that's pipe dream single purpose single tenant CDN for changelog.com that runs Varnish cache the open source one on flat.io

so we've been 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 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 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 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. It runs just test. And when we, 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.herl files. And what does it look like? Well, let's have a look at this fast changed changed so we're going to look at files changed there's a workflow which runs it and it just just tests 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 2. You can specify this in the file when you do 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 repeats too, 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 PyDream. 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. I didn't get like a nice waterfall, like to see how much like 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 test's 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 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 hit stale should not contain string stale and it does and also 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 varnish config specifically. This is testing the actual running nodes.

Like this is the thing in production that is testing, right? Yes, that's it. Okay, so it's almost like an integration test. It is an integration test, yes. How would you use it for development then? Right, so this is the big thing which 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 TDD some 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. I couldn't tell if that was a rhetorical question or not. No, no, no. Here's the questions 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. That's it. And so that's outside of our control. 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 PipeDream

and not spin up an entire working system with nodes around the world and stuff like that. 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.

Yeah. 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 playbacked, played back. Yes. Yes. And then we avoid production altogether. VCR. Remember VCR? Yeah, exactly. For people that don't know Ruby or 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. course vcr and the cassettes and damn it i had to recreate them so many times right right but yeah i remember that yeah it's a it's a ruby gem which basically allows uh 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 og vcr yeah i hated those movies because the quality was so bad and like the more a 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 you can but like generally most people assimilate or you know think of the vcr as you put a cassette in yeah you play it, is all I'm trying to say. 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 going to 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? Right, a 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.

SGTM, 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. So one that we liked, that we all liked, let's like, like a who is.

Oh gosh. Who is, let us do who is. Do you remember the domain which we wanted? No. 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. Ah, for shame.

Yeah. I mean, it says it's already registered. You can't even register it ah so for shame yeah i mean it says it's already registered you know there's no info yeah dot li domains are are difficult for various reasons so what was what was the other tld that we wanted tech pipely.tech let's see if pipely.tech is available no someone registered it when did they register it let's see what happens if you go to pipely.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 this is us get out of here these are three 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. New things get born. So a CDN is born. The stars in the sky. The CDN is risen. I don't want to burst your bubble, Gerhard, but it wasn't three magi three wise men yeah what was it well it's a group of wise men there was three gifts given

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're going that looks like a futuristic city out there yep certainly that's not uh jerusalem or no bethlehem or anything in the in the story looks like dubai it does look like dubai so you know maybe a modern take but uh 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 if you go to pipely.tech, it's a domain and it tells the whole story. So should we build a CDN? I can click on that.

Oh, cool. 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 more. 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 Pipeley story, whichever you like, I like the name Pipeley. I'm sold on it. You sold on Pipeley.

Well, you bought it, Pipeley.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. Pipelea's coined.

Can I share some behind the scene nuggets? Of course. This is fresh. This is on a pod coming to you soon. Actually, next Wednesday. So on Wednesday of this week, which is the week of, I guess, the 4th? No? What was Monday? The 2nd? Monday was 2nd. Yeah, yeah, yeah. 2nd.

December 2nd. 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 one of the founders and CEO of Fly.io, which we know and love here. Obviously, I love Fly so much. It's so cool. And during that conversation, because 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 we said it and I'm the one that said it, but, uh, or 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. I mean. You did. Yeah, I did.

I just had the execution. Like, hey, 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 futuristic 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, like Jared said 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'll say this on the air, I think I

said this in in face to face but he said to me he's like Adam when you tell me new ideas it's like 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 kind of bummed me out because I'm generally not so much the idea guy but like someone sort of like generating vision in some way, shape or form. And like, when he said that, I also thought in my brain in the moment, like, gosh, I've kind of stopped like casting any sort of vision in my own brain because I'm kind of tapped too. So like, 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 cash all of your content on all their pops across the globe forever. That's not in their best interest. There's cash misses, not because they can't cash it, because they don't want to. And so the CDN we build, that we want to build, will always cash everything you need to across the globe. And it will only expire when you say this is expired.

There will never be a cash 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 recurring 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, 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 i honestly see this improving a bunch of things and if it doesn't

work out it may not work out the story is 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 came, we saw, we dreamt. We pipe dreamt. We pipe dreamt. And we pipe lead. We pipe lead. Pipe lead. Dot tech. The pipe piper. We'll 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. Looking back 10 years from now, 20 years from now,

be 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 Pipely the company or anything like that. I mean, like, our usage of Pipedream.

Our usage, okay. The thing becoming real for us as the first, in quotes, customer, if that's the thing. Like, 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 back end 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, right? 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 only want you to pick it up,

you realize how much all the rabbit holes we still have to determine if the way we send logs the fast way is the way of the future we know that we like a lot about what that does real time I'm assuming that's what you mean by that so it's more around making sure

that we send logs to Honeycomb so we can understand what's happening in the system we want to keep the same structure as 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 no interruption of service or 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 Pipe Dream and the roadmap. So we need, for stats We also need to send logs to S3. This is something that Jared mentioned last time when we talked about Pipe Dream and the roadmap. So we need, for stats, we need to set just like to keep the compatibility, right?

What about swapping out taggers 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 implements its 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 Pipedream necessarily. So it could be send logs to R2, but we want to keep the exact same format so that our analytics stuff doesn't get rewritten.

Exactly, yeah. So that's why we do 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. So the application itself will know which are the pipe dream or pipe instances and will send these these purge requests and we're looking at the fly i o 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 flat at io to implement this purge via OBAN and 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 you're 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 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? The possibility of these Jedi wise dudes bringing to fruition the Pipely dream? Yeah, I think Pipely is a good idea. New seeding 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 it a good idea? So we weren't like all in to begin with. And I think, I think that we are getting close to being all in as in let's go for this. Let 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 are, I would say, maybe a third way through, maybe a quarter through, something along those lines. And there are 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 Mararnish 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 Varnish 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. Datadog acquired them, you know, 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 Docker infrastructure. This is a very important component and 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 do it, right? Let's do it. So excited. Good stuff, Gerhard. Always, 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, uh, we've stood the test.

You, you've been here, Gerhard, since the, the proverbial beginning, you know, the new beginning, the,

the latest era, not including this new one we're about to go on to. Yeah, 2016, like. 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 it's, 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. OMG. 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 will 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 going to be a banger. Mitchell Hashimoto joins us for a deep,

deep dive on Ghosty, 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 sotl 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. Finally the end of changelogging friends With Adam and Jared Some other rando We love that you loved it

And stayed until the end But now it's over It's some other rando We love that you loved it and stayed until the end But now it's over, it's time to go We know your problems should be coded And your deadline is pretty foreboding Your ticket backlog is an actual problem So why don't you go inside? No more listening to change-locking friends From Adam and Sharon to Silicon Valley

No one gave a gag, we'll come to an end But honestly that will probably be our finale You best be slinging ones and zeros And that makes you one of our heroes Your list of to-dos is waiting for you So why don't you go inside? No more listening to change-locking friends I'm bad at me- and Jerry and people you know. Change Lock and Friends, time to get back into the flow.

Change Lock and Friends, Change Lock and Friends, it's your favorite ever show. Favorite ever show.