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 and 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. All right. Let me screen share it. This is you kaisening archives and 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. Screen, window, boom, boom. There you go. Tizen 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 using it for seven, eight years. So I-A Presenter is.
This is I-A Presenter. 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.
And so as part of that idea and mantra, we have decided to change things in 2025 to focus solely on making this podcast you're listening to right now, The single best developer podcast experience. News on Monday, interviews on Wednesday, Fridays on the weekend or on Friday mostly. And that's going to be some fun stuff. So that's what we're doing. Some of our favorite shows are going away.
Transitioning, moving on, spinoffing, continuations. But that's what we're doing.
What do you think? Was this a shock to you? It makes sense. I was surprised when we talked about it. Honestly, I could see it coming. I mean, it just makes sense. It resonates with how I like to approach things. And it just fits with that mentality. Double down on the thing that you're enjoying 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've 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 to get to where we're trying to go. And it was a struggle because it's not easy to retire something, move on from something, to give someone or an entire world of audience bad news. And that's not something that you do quickly or lightly. You do it with intention and precision.
And even then, even when you do it precisely and with precision and intentionality, it's still hard to get it right. 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 that. Continuation. Actually, every one of them does. JS Party has a new show called Dysfunctional.fm.
Nick, K-Ball, Amy, GoTime has a spin-off called Fall Through.fm. Chris, Ian, and more. Extended friends from our existing podcast. Family of people who listen. Ship It has its own spinoff called FAFO.FM. Folk around and find out. Cool. Love that. Justin and Autumn. And then Practically I, they're keeping their name because Chris and Daniel were unique. We've been working with them for many years.
Probably the longest running show. And independently, they had no other panelists.
It was just those two, yeah.
Just those two for many years. And, you know, it's just a labor of love to produce these shows. It's a treadmill in the media world. And we've been doing this for 15 years. It's not like we've been doing this for a day. You know, we've got some reps under our belt. You know, we're swole, so to speak, in the podcast. 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 costs there, not doing it. We've missed out on audience growth, connection, more in-depth content, etc. 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 was called cpu.fm. I think it has big opportunity. And so I think if people continue to trust us, join cpu.fm, let us support them. But they produce their own shows.
We're no longer part of the media machine they are, where we're helping them ship shows daily, weekly. That's a tough one. It's arduous.
Yeah, I think that the end result of this, 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 100, 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 JS Party.
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, 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. Change happens whether we like it or not. This way we are in control. Gaining something, losing something, you know, it's 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 greener. But the joy of missing out, right? The Jomo. I really like that take. The Jomo. The Jomo, exactly.
This could be it, another baby title idea. The joy of missing out.
That's the first time I've heard that.
Oh, really? It's brand new to me, right to this moment, yeah. I think I've heard it first from DHH. Oh, really? Yeah, the joy of missing out in the context of remote work. Of course he would make that up. I'm sure he did. I don't know. The point is, 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 ax 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, like he's, he's sponsored. You know, we've had this ceiling of ability to help folks because we have limited shows. I really believe that Jared and I are pretty good tastemakers. And I think the idea with CPU is pretty cool. And we want to help more of those brands reach more developers. And we had a ceiling.
I would often tell folks, because I'm a big, big helper when I 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, you know, 10 or 15 podcasts with an index, with a single subscribe point for many really awesome developer podcasts that join this community. 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 I think more importantly, helping developer brands reach developers is really, really hard.
The ones who have a good story, they're just so new. They need great awareness, but they're just so 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 or there's no, it was just like, of course there's the work of scheduling and rescheduling and sponsors and this happens and that happens and we got to get the thing out. Like that's all just work, right? Of producing podcasts.
But I got to a point where we're doing these seven shows a week, and this is relevant to Kaizen, that I didn't have any bandwidth to actually experiment. 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 just have not been writing enough software lately. I want to build stuff more. And I just didn't have any room to breathe. And so I literally would just do Kaizen-driven development, which is every two and a half months, right? Like, please don't look at my commit messages between the last, you probably already did, between the last Kaizen and now. It's not very much.
I just don't have the bandwidth. And that's not good for our show. That's not good for me personally. That's not what I want to be doing. I want to build stuff more. And I'm so excited as we do laser focus on the changelog, as we do take these productions off of our weekly calendar, even though the shows will exist in spirit as other people's productions. I got room to breathe. I got room to code.
I can block an entire day and just be like, I'm going to build something today. And that, I think, is a huge benefit to this particular change. Which brings us to the work you've been doing, because I haven't done Jack Squat, Gerhard. Hopefully you've been Kaizen-ing, 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.
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. There's nothing changing about Kaizen. Kaizen is now embedded into the ChangeLog podcast itself. Just to be super, super clear, it was implicit. It will be more explicit here. There's nothing changing about Kaizen. In fact, I think it won't get more frequent.
I think it might get better because I think, Jared, to your point, I think you and I might have more time to do more development to make... us less like Gerhard, what did you make? So that we can have a podcast.
And some iteration and some change. So to everyone listening, I want you to know that this conversation has been thought out weeks in advance. You're at the baseline. It only gets better from here. 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 trust me the last the last thing i'll be 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
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. One. 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.
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. You may have seen it in clips, but you haven't seen the full length.
And you can hear Gerhard's joy in his voice, but you can see it in his face even more.
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're going through the show. Oh, nice. So hopefully it won't be just my laughter.
It'll be everyone's laughter because you'll go a bit crazy. Okay. But in a good, tasteful way.
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 and to the apple store.com, whatever the website is and priced one out. My trepidation is like, we really maxed out these Macs that we're currently using. Like my current MacBook pro, which is a 2021 M one max. Yeah. It was the first M, but it was the maxed CPU and, 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. Now, in all honesty, I know that a few listeners have tried. I forget who exactly it was. There was someone that mentioned that a lot of work has gone into it. Do you remember that, Jared? It was in one of the comments, maybe. I forget his name. That's all I know. 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 home lab into production. And so that happened. Nice. 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-sized home lab, which is insanely powerful. You can run Kubernetes on it, 16 cores, DDR5, multi-terabyte NVMe drives, and it can serve 300 billion requests per minute. Sorry, per month. Sorry, that would be crazy. No, no. We're having billions. 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, 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. okay always and for this both of you you'll need to take out your browsers okay and you will need to go to jellyfin oh dot make it work dot tv are you going to share with us your home theater setup or what
Uh, 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. 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 Pipe Dream CDN. This was August. It took me a while to edit the video. Did it load, by the way? Yes, it loaded.
I just had to pause it so I could listen to you talk.
It's running smoothly, too. Excellent. So this video is running off that LattePanda Sigma. It's being fronted by a CDN. So it's turtles, turtles and turtles. And this is the content which I always imagined I would produce, content that has the conversation part and content that then we do screen sharing and we go deep.
The content that you're looking at is about an hour, the whole thing, the whole hour. And it was edited down from about three hours. That was a long conversation. And it's still a draft. So it hasn't been published yet. But it's coming. So taking the 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. There's also makeitwork.fm, but makeitwork.fm is just for the conversations, just like the audio part. So that's how this works. Nice. Love it. So changelog is very embedded in this because, 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 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. It's amazing. But anyway, back to Kaizen. Back to the Kaizen 17. So we talked about the CPU-FM. 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. 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 function, Is it a toolkit? Is it a library?
I would call it a CLI utility. It's like a make. It just improves on make, basically. If you've used make, that's what a command runner, some would say. Right.
So we'll just call it this CLI utility. tool that you made the change easy and now you're making the easy change call back to the previous episode call back to of course Kent Beck's first make the change easy warning this may be hard then make the easy change
classic quote from Kent Beck because this was like a pretty easy change for you it looked like in terms of this particular one now you had some neon things to do but you can tell us about the details of how it worked the PR itself seemed pretty straightforward and small and then it worked so that was my experience very nice I'm very glad that you experienced it that way I'm curious when Adam tries it out how well this works for him
The idea is that we wrap a bunch of commands that you would need to run locally. So for example, installing the Neon 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, like I thought this change would be easy, but actually there were like quite a few rabbit holes that I had to go down on. One, for example, was how to download in the format which is compressed, right? Because you don't want to download many gigabytes locally. So how do you compress it automatically? And then how do you handle extensions that exist on Neon?
They're installed on Neon, but you don't have locally in your Postgres database. So there was that as well. So I had to uninstall an extension, which is 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 restored devdb from prod. That's exactly how we call it.
And you can look at the pull request. There's even a video which just shows how it works. It wraps all that complexity, like all that know-how. You have to run this command, and you have to pass this value. And the other thing is the credentials, they're pulled just in time from the 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 thing to wrap your head around. There's nothing complex about what's like, obviously there are a couple of niggles to sort out, but you don't see them when you use it. And you can even like see the commands before they run. You can copy paste the commands. So everything runs locally.
And I think this was the hard part before because when we were using Dagger for this, that was running in containers, but you don't use containers. So we had to make that big change so that you would have this nice local experience. Everything runs again. It doesn't need Docker. It doesn't need anything like that. It doesn't need Dagger. It's just commands, installing binaries, things like that.
So I'm glad that you tried it. I'm glad that it's working. Do you see yourself using this?
Yes. Immediately, yes. It's just so straightforward. I mean, all the things that you just said right now are things that I love. And so I'm way more likely to pick up this simple tool, especially following your example, than I was, honestly, even with The old 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 and it's formalizing it into a shared repository, I'm way more likely to follow that lead and create additional just commands. And now I have time too. So I'm totally into this Gerhard. 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 of limitations because, you know, Adam, like if, you know, on your machine right now, 100% you're not working inside of a Docker container doing this discussion, right?
It's just very different. So there's a lot of software expectations that actually don't really work inside of a container. An example is a customer of ours is Square, and they do stuff with a payment terminal. And so they need essentially like hardware accelerated Android. That is just really finicky to get working in a container.
You totally can pass 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. OK.
Will you ever have an interest to try this command?
So this creates a new branch on Neon.
Not just that, it also configures your app. It starts your app with that Neon branch. So there's no more manual, it's like one command and it will run everything. It will create the branch and then it will configure your app to use the branch. There's no more manual dicking 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? Yeah. 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. 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 freshens 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. 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 you're going to do it once a week, maybe. It doesn't bug me to have the five minutes.
If I was doing more experimenting and changing and stuff, I think having these immediate branches without any sort... 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, for example, Adam's
case where you know sometimes it fails and then you don't like what state am i in this command tends to be self-contained in the point 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 it will do the right thing and it's all embedded in the actual command
Now, this command, when you're connected to a remote database, it can be slightly slower. So for me, for example, I preferred downloading all the data locally and having all of that locally because it felt snappier. And even though the query planner, we warm up the query planner so that things are cached, we do a couple of things like that, it still feels slower.
It still is slower because it has to do all those round trips, right? And they're all remote. They're all remote calls to this remote database. So I think the choices between paying the penalty once, five minutes, three minutes, depending on your internet connection to load all the data, and then you know you have the latest, or...
Pay a little bit of penalty every time you load the page because it may take, I don't know, a second slower sometimes, depending on how many queries you're running. So both options are there. I think knowing Adam, I think he would prefer the second option so that he's connected against a remote database. And I think 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 Zulip or Zulip. Everyone's there. The conversations are there. I won't call it Zulip, Zulip, Zulip. It's just a joke. So everyone migrated to Zulip. How does it work?
Amazing. It's awesome. I think it's easier to track and follow better than Slack. When I go back to Slack now, I feel like I'm in some sort of archaic way of communicating, which is just like, just throw it at the wall, and if you see it, cool. You can't compartmentalize conversations.
Threading is obviously there, but it's not the same as Zulipit's threaded conversations for teams is what their mantra is, basically. The one key thing I think that makes it look 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 is it that important? Maybe that's what stops you from communicating. Right. 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. Cause 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 the different podcasts, their episodes. You can comment on a Kaizen 17, for example.
It's really compartmentalized, which I like a lot. And those threads are long lived. 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 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 realize actually this allows me to be more focused. I can just pick a thread and I'm there. That's the context. I can see it everywhere. So I can see everything that was discussed in that thread. So that's really cool.
Also having a thread per episode, I think that's a great idea.
i cannot remember how many times there was a comment on an episode on the changelog website which i just couldn't find i couldn't find how do i get to the comments on an episode now so much easier yeah i think that's been really nice especially for podcasts where they are consumed not just asynchronously but 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, anytime you live somewhere for a while, you see all the warts.
You know, 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 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 yes we are living in a little bit of a blue green i would call it blue long blue yeah it's a blue green deployment yeah exactly and there's lots of green on this side of the grass but it's not entirely there yet yeah do you see us shutting down slack at some point
Sure hope so. We certainly can, especially for just like the public discussions of like, there's no, like Slack is cut off at this point in terms of joining. Like the website is all, you join the community, you get invited to Zulip. You can't get a Slack invite unless you go inside of Slack and invite somebody.
And so it's like essentially cut off from the world and there's no conversations happening there in the public. Right.
at all every once in a while somebody will say something mostly they're spammers our new episodes are still posting there I haven't quite made that change yet I figured we'd do some sort of more big announcement first and like encourage people who are still in Slack one last time to come over to Zulip but we do have a lot of team chats and private chats that are ongoing and used so
that we haven't quite gotten cut over to. And some of them, like I said, are with like folks from partner podcasts and stuff. I don't know. We haven't decided if we're going to actually like 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.
I, you know, my real hope, I suppose maybe if I rewinded prior to Zulu, my, I have two hopes. Uh, I would love Slack to support communities better and support, uh, non enterprise, not so that they can, uh, 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 Maine at one point, not all of them active, but if we had to pay for everybody in there, OMG, we would go broke, right? We can get it sponsored maybe, but then it's like, well, does that really add value to a sponsor to support that Slack channel? Maybe. I mean, there might be ways we could do it, but it would be kind of maybe icky to enable that.
So I just would love Slack to revisit the idea of the ubiquity and embeddedness that they have with developers and the community aspect that just doesn't get to foster without paying large sums of money. Find a different business model that supports those folks. I think you'd change some things. Second, I think that Zulip has so much potential.
And I say that not in a negative way in the fact 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'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 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 Zulu 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 an install and just install worked pretty cool. I then ran just contribute and wow, yeah, that does a lot. It worked though. So just contribute worked for Matt Johnson, September 2024. So now I know how to find it. It was in Zulip all along. 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.
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 if you want to get straight to other people's conversations. 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 once I've seen these chapters, that was the point like, wow, 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. Mm-hmm. Because it might 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. They just take texts, they convert them automatically.
Hence the workflow challenges we've talked about in the new era for the ChangeLog podcast universe.
The question becomes, do we have one artifact that is identical in both platforms? Or do you have a slightly different show on YouTube than you do in the audio world? 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 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.
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?
So there's like a lot of those kind of, and then all of a sudden now you have basically two shows you're doing for the price of one. And so, yeah, we're still figuring all that out.
Yeah, two cuts. It's like a director trying to do like, oh, here's the extended cut and the theatrical and the, 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 Ridley Scott, that was much worse because he likes his original cuts better first. Wow.
Sometimes the extended cuts are much worse because it's the director being entirely up their own butt with their love of their story. And it's like, no, the cut was really good, actually. Your editors are excellent. Other times, the extended cut's awesome. So it is hit or miss. 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 Ziggler. 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, 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 inside our app, like... 30 lines of code, you know, for the module that changelog.zoolit module, which invites people and posts stuff. And once you can post stuff, then you're just basically, you're halfway there. Now, how does this work? Honestly, I don't recall.
Is this going through GitHub Actions? It is, yeah. So from GitHub Actions. Okay, so this probably isn't even my code doing this. It's probably just a GitHub Action I installed.
Yeah.
All right, how'd I do it, Gerhard?
How'd I do it? Let me open it up because it's been a while since I looked at that. And there's no pull request. There's code. So I have to go look at that. That's me. That's me. No pull request. And it's spread across a couple of actually commits. That's also me. Yeah. So you recognize that.
This is how I roll.
That's how you roll. It is.
I cannot 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 I 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 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. 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 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- I was tweaking it. That integration, exactly, yeah.
All right, so yeah, it's just basically you use an existing GitHub action and you tweak it to your liking. Yeah. And so it's even easier than writing your own API client, which I did for all the other integrations. But yeah, this one was so easy I forgot.
Yeah.
Well, it looks good. It works well. I was very happy to see this. And it's in the Kaizen channel. It's exactly where it needs to be. Code deploys. It's all there. So you can go and check it out. That's very nice. So the one thing which I had to do as a follow-up, pull request 536, right? We have two of everything. We are running the primary deploys through namespace.
They run Dagger for us and they run the actual, the CI and CD 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 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. 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, no, no. I went too far. I went too far. Hang on.
I'm doing this like as a live edit and I don't want to. He's live editing his slideshow. Cool. For those listening. B is $1 and C is $2. 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. Too obvious, exactly. So maybe I could have done like 0.5. It was, yeah.
That would have made more sense. There you go. 0.5, so I fixed it. So half a buck. Half a buck. For a month of namespace.so. Yeah. Concurrent runners, that's what they're offering, right?
Mm-hmm. It's a fast 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 you just get more insights into what's happening when the builds run.
Right. Not a sponsor, but they certainly should be.
I think so.
They're on my list. I really think so. Put that on your list, Adam.
Okay, cool. 2025, name.so.
$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 a basic, but yeah. Pull request 535. This was also a follow-up. We improved on the Zulip auth integration.
so this is my problem this is my fault too yeah you remember it 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 all the secrets so that's what the 535 is yeah i just forgot about that so i just did the old-fashioned way and so thanks for fixing it that's we have to have everything
You want to back up. You want to back you up.
Yeah. Cool.
What's up, friends? I love my eight sleep. Check them out. Eight sleep dot 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 Eight Sleep 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.
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. off the pod for ultra. When you bundle it again, the code to use is changelog and that's from November 11th through December 14th. Once again, that's eight sleep.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, and that's the pipe dream. Yes. What is a pipe dream? Tell us, Jared.
A pipe dream is a world, a future world. In a world. In which, ooh, 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. Mm-hmm. And you don't need to have a CDN anymore because you've built your own CDN. And it makes sense. And you can just open source it and share it with the world.
And everything's simple. And you got 20 lines of varnish, maybe 50, maybe 100 lines, maybe 200. You have to update us on the lines of varnish. Still 60.
We're still on 60. That has not changed. That's pipe dream. That's pipe dream. Single purpose, single tenant CDN for changelog.com. It runs varnish cache, the open source one on flat.io.
So we've been working towards this. You've been building it. Last time around, I remember saying, I can has test suite or something like that. Yeah, pretty much. And I know I looked at a test suite pull request. So I think I know where this is going.
Yeah. So the issue that Jared opened in the true open source spirit is wire up a test harness. That's right. Because I said, create an issue, open source for the win. That's right. And you did it.
You know, I opened that issue after listening to Kaizen 16 and hearing it back and you telling me to open an issue. And I was like, oh, I never did. So there I went. Did I even quoted myself? And I quoted you in the issue. Yeah.
Very nice. You did. That was amazing. So that was issue two. Issue two. That was a pull request, pull request three, which adds tests. Yes. So what is interesting about this? Well, we're using Just. Right. Same as before, one tool. We seem to be standardizing on that. It runs just test. And when we run it, it creates a report. Why does it create a report? It uses this amazing tool.
Many have heard of it. Hurl, H-U-R-L. Not sure if it's the best name, but anyway, we didn't pick it. Hurl.dev. And hurl.dev is orange open source. It's a CLI that, actually it's more than a CLI, but you interact with it through a CLI, which allows you to write tests and assertions about HTTP requests. So the focus is on testing HTTP endpoints.
And it's written in Rust, which means it's really fast. It has a very simple DSL. You put it in .herl files. And what does it look like? Well, let's have a look at this fast changed. So we're going to look at files changed. There's a workflow which runs it, and it 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. Right. We also check that there's a... X varnish 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 3 on the pipe dream. And again, there's a video. How does this work? So I'm just going to play through it. There's no sound. But the thing which I wanted to go to is this report, which is really cool.
So after you run the test, you can have a look at the output, which shows you exactly the requests, how they happened, what headers were sent, how did this behave, which I think is really cool. Did you try running this locally, Jared? I watched your video. I didn't try running it. Excellent. So the video works.
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 tests passed without the report, right? The report's an additional thing. It's not like the output.
That is correct. Yes, that is correct. So the report is separate. So the report is separate from whether the test was successful or not. And right now, this commit has failed. So this test on main has failed. So we see the failure. And the failure is that string edge grace hits stale should not contain string stale. And it does.
And also the age, like how long this has been cached for, we expect it to be less than 60, but it's been 67. So the system doesn't seem to behave the way we thought it would.
So this is testing not the Varnish config specifically. This is testing the actual running nodes. Like this is the thing in production that it's testing, right? Yes, that's it. Okay. So it's almost like 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 question that we need to answer so that we know how do we want to continue developing this? Because based on what we choose, there's almost like different trade-offs and different levels of how hard this is going to be. So do we, for example, want to run the entire changelog app locally?
And if we do, then we need the database as well, which we can do. It's not a problem. And then we put varnish in front, which is the one that we developed 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 like that's outside of our control, right? So we don't want to test that that thing's working as it should.
So I think we just want to keep it isolated to Pipedream and not like spin up an entire working system with nodes around the world and stuff like that.
Okay.
Does that answer your question?
It does answer my question, yes. That's exactly what I was thinking. I just want to double check if you're thinking about it the same way and it seems that you are, right? We only care about the configuration and Pipedream itself. Yeah. And how it interacts with origins, different origins in this case, 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 vcr yeah for exactly for people that don't know ruby are not coming from that world like the moment you said that like of course vcr and the cassettes and damn it i had to recreate them so many times right right but yeah i remember that yeah it's a it's a ruby gem which basically allows http requests to be recorded and replayed so that you don't make the real requests that's right and for those people who are even
less old. Originally VCR was a tape based medium in which you could record and playback television.
The OG VCR.
Yeah. I hated those movies because the quality was so bad. And like the more you watched it, the worse it would get. The worse it would get because yeah, the media would degrade. So yeah, luckily we don't have that problem anymore.
Plus my original Star Wars VCR, which was recorded off of television. It got recorded over like halfway through for like a basketball game or something. It's like, goodness gracious, man. I'm trying to watch Star Wars here.
You know what's funny about VCR? It stands for video cassette recorder. But you would use a VCR to play.
primarily right as a user you could do both for both I know you can but like generally most people assimilate or you know think of the VCR as you put a cassette in and you play it is all I'm trying to say is like the general usage is not so much the R part of it it's the VCP video cassette player
I think what we learn here is separation of concerns is a good thing. You know, 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. Right. 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.
Okay.
That's right.
So we threw around a couple of domain names. Correct. So one that we liked, that we all liked. Let's load like a whois. Oh, gosh. Whois. Let us do whois. Do you remember the domain which we wanted? No. I doubt it. So it was pipe.li. Pipe.li. That was, I think that was already registered as far as... No, it's unavailable, actually. We can't even register it. Oh, okay. For shame. Yeah.
I mean, it says it's already registered. You know, there's no info. Yeah. .li domains are difficult for various reasons. So what was the other TLD that you 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, my. Somebody else has the idea. A new CDN is born. What do we see? It looks like it. What? What are we looking at? Three. This is us? Yeah.
Get out of here.
Are these, these are.
The three magi. Oh goodness. It's Christmas.
New things get born. So a CDN is born. The stars in the sky.
The CDN is risen. I don't want to burst your bubble, Gerhard, but it wasn't three magi. Three wise men? Nah. What was it? Well, it was a group of wise men. There was three gifts given, 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 these were Jedi at first, so I thought you were going, that looks like a futuristic city out there.
Yep.
Certainly that's not Jerusalem or Bethlehem or anything in the story. Looks like Dubai.
It does look like Dubai.
Yeah. So, you know, maybe a modern take, but hilarious. A new CDN is born. Pipely. Coming what? Coming on the 25th or what are you trying to do here? Maybe.
I don't know.
So pipely.tech.
So if you go to pipely.tech is the main and it tells the whole story, right? So should we build a CDN? I can click on that. Oh, cool. That's us. Always three. That's interesting. So three seems to be the theme here. Always three. Well, two, three. So we're going. 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, that's as well with nice screenshots we have. So the whole story, the whole Pipely story, whichever you like, I like the name Pipely. I'm sold on it.
You sold on Pipely. Well, you bought it. Pipely.tech.
Yeah.
It's a thing now. That's the one that I remember. Yeah. I like it. I'm so down.
Like beyond so down. Can I share some behind the scene nuggets? 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 Pipe Lee until this moment.
In terms of a name, I laughed so hard the last time I said it, and I'm the one that said it. But... 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. Yeah. 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? Yeah. That is so cool. Yeah. I mean. You did. I just had the execution. 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 face-to-face, but he said to me, he's like, Adam, when you tell me new ideas, I just 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, right?
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. He said, well, you know, Adam, that Fastly and Cloudflare and every CDN out there, 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 like that, that world. And I think people don't need, and this is even Kurt concurring this, like, 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 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, we saw, we dreamt. We pipe dreamt. We pipe dreamt. And we pipe-ly. We pipe-ly. Dot tech. The pipe-piper.
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 pipe dream.
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. Okay. 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 backend, 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 don't, only once you pick it up, you realize how much, like all the rabbit holes.
Well, we still have to determine if the way we send logs, the faster way is the way of the future. We know that we like a lot about what that does, real time, et cetera. I'm assuming that's what you mean by that.
So it's more around making sure that we send logs to Honeycomb so that we can understand what's happening in the system. We want to keep the same structure as Fastly so that all the queries will work. So there'll be like no interruption of service or like no big changes. So that's why I mentioned this. We just need to have some way of sending all the request logs to Honeycomb.
That's what I mean by this. We also need to send logs to S3. This is something that Jared mentioned last time when we talked about 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 Tigers for that? Or MinIO or MinIO if we wanted to not S3 it?
Is there any reason to not do that? It doesn't matter where we send the logs as long as we send logs to an S3 compatible API. Gotcha.
Which I tried to switch over to R2, by the way, but... I couldn't because of the way R2 implemented streaming versus the way S3 does and the way Fastly actually pushes over to that.
Interesting.
And so we could have been on R2 entirely, but we're actually in both now because our logs still go to S3 and everything else goes to R2. Now, we wouldn't have that problem inside 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 once that's why we do like the first part, which seems a bit easier to just send the requests, it doesn't matter which way you do them, honestly, but this will ensure that the service behaves the way it should. And I think this is more valuable from a functionality perspective. Then fairly hard to implement purge across all app instances. I say fairly hard.
Oh, man, I can see me and Jared getting together here because we need to figure out how to purge these correctly and how to do this from the app. So the application itself will know which are the pipedream or pipely instances and will send these purge requests. And we're looking at the fly IO machines, like we're running the same network, we can discover them, we have DNS.
So a lot of the building blocks are there, but this is where the application needs to come together with the actual CDN runtime, in this case fly.io, to implement this purge via OBAN and like how we do things. So we don't introduce a third or an extra service. And then adding the add redirects, this is really easy because it's just basically adding more VCL config.
Most of it is copy paste, maybe a few adjustments. So it's very feasible. And we're talking, I would say maybe weeks of work in total, but weeks of work spread over a long period of time. That's what's hard. Like the time on my part, you know, have the time to actually go through all these things, but I can make this my focus. That is a possibility.
Where should we end this pod? Should we end it right here? The possibility of these Jedi wise dudes bringing to fruition the Pipely dream?
Yeah, I think Pipely is a good idea. A new city and he's born. I mean, we can see... The journey that we've been on right since January, that's when he started talking about 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's implement it, let's see how it would work in practice. Most of the problem space, I think we have discovered it. We know what are the big items, not the actual implementation.
But this seems a lot more feasible and a lot more realistic than it was in January, for example, when it was just a question. And I think now it's not like we're building it. It's like we are, I would say, maybe a third way through, maybe a quarter through, something along those lines. And there 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 Manj 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 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.
2015?
Yeah. 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 brings me a lot of joy. That's all I'll say, I guess. I'm excited. Pipely.tech. We have it. OMG. We have it. It's real. A new CDN is born. Let's do it. Kaizen. 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 Ghostie, his new terminal emulator that's so good and shipping out to the public before the end of the year. And on Friday, our seventh annual State of the Log Spectacular. It's almost too late to get your voicemail in, but if you're listening to this on the 13th or maybe the 14th, go to changelog.fm slash 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 and some other rando We love that you loved and stayed until the end But now it's over, it's time to go We know your problems should be coding And your deadline is pretty foreboding Your ticket backlog is an actual problem, so why don't you go inside? No more listening to Changelog and Friends, from Adam and Sharon and Silicon Valley.
No one gave a gag or come to an end, but honestly that will probably be our finale. We best be slinging ones and zeros. And that makes you one of our heroes. Your list of to-do's is waiting for you So why don't you go inside?
No more listening to Change Lock and Friends With Adam 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