The Changelog: Software Development, Open Source - Reverse rug pull, so cool? (Friends)

Episode Date: September 13, 2024

Jerod & Adam share our Zulip first impressions, react to Elasticsearch going open source (again), discuss Christian Hollinger's blog post on why he still self-hosts & answer a listener question: how do we produce podcasts?

Welcome to ChangeLog and Friends, a weekly talk show about how we podcast. Special thanks to our partners at Fly.io. Over 3 million apps have launched on Fly, including ours. And you can too, in five minutes or less. Learn how at Fly.io. Okay, let's talk. Hey friends, I'm here with Dave Rosenthal, CTO of Sentry. So Dave, I know lots of developers know about Sentry, know about the platform, because hey, we use Sentry and we love Sentry. And I know tracing is one of the next big frontiers for Sentry. Why add tracing to the platform? Why tracing and why now?

When we first launched the ability to collect tracing data, we were really emphasizing the performance aspect of that, the kind of application performance monitoring aspect. You know, because you have these things that are spans that measure how long something takes. And so the natural thing is to try to graph their durations and think about their durations and, you know, warn somebody if the durations are getting too long. But what we've realized is that the performance stuff ends up being just a bunch of gauges to look at. And it's not super actionable. Sentry is all about this notion of debuggability and actually making it easier to fix the problem, not just sort of giving you more gauges. A lot of what we're trying to do now is focus a little bit less on the sort of just the

performance monitoring side of things and turn tracing into a tool that actually aids the debuggability of problems. I love it. Okay. So they mean it when they say code breaks, fix it faster with Sentry. More than 100,000 growing teams use Sentry to find problems fast. And you can too. Learn more at Sentry.io. That's S-E-N-T-R-Y.io. And use code CHANGELOG. Get $100 off the team plan. That's almost four months free for you to try out Sentry. Once again, Sentry dot I-O. The only Bob Seger song I could name is Old Time Rock and Roll.

That's like the worst one. Well, I don't know the man's... All Bob fans kind of hate that song. I don't know the man's work, obviously. You're missing out, man. I'll have to give you his greatest hits. It's on Spotify. I'm sure it is.

I don't use Spotify, though. I only program against it. I've been coding against Spotify this week, so... Mm-hmm. I'm this... I finally cracked it, man. I finally cracked it. We're going to get our data out of there. Is that right finally cracked it, man. I finally cracked it. We're going to get our data out of there.

Is that right? Got it, dude. I'm pulling data out of their unofficial API. It's cool. Is it legal? I don't know, honestly. I'm not sure it's not illegal. Well, I'm not sure it's not illegal.

It's one of the two. They had terms of service. It's either legal or illegal. I don't know. It's one or the other. They have terms of service. It's either legal or illegal. I don't know. It's one or the other. I mean, listen, they let you log into a dashboard and look at it.

So that's all I'm doing. Only it's a robot. I love it. I love bots. A robot doing it for us. You know, I used to like bots more before there was artificial intelligence and now they're kind of scary.

Bots were controlled by us and now they're kind of like maybe not controlled by us. So like when I said I like bots, I kind of cringed internally, like maybe I don't. I don't know. I feel like we still control them, do we not? I mean. So in the Babaverse book five. That's the deep cut that I don't have any access to.

That's okay though. That's okay though that's okay i think it's in this in the synopsis of the book where it's not plot ruining but there's a premise of artificial intelligence not being nice okay let's just say you know it's trying to escape trying to be nefarious sure and it's a little scary it's just say, you know, trying to escape, trying to be nefarious. Sure. And it's a little scary. It's just a book though.

That's just made up. For now, until five years from now when science fiction becomes fiction. I'm skeptical. All right. I should say, sorry, nonfiction. Yeah. I was going to correct you, but then I was like, I know what he means. You know what I mean? Yeah.

Yeah, totally. And like an idiot. I still can't. I never, I'm like, is it nonfiction or fiction? Every time in the moment. It is kind of backwards, isn't it? It is. Because one's the negation of the other. Yeah.

And you think you would start with the real thing and then negate it for fiction. And then the movie ruined it for me, Stranger Than Fiction. Stranger Than Fiction, that's Will Ferrell? Will Ferrell. I never saw that one. It was a strange movie. Was it Stranger Than? But it was fiction.

It was good. It was a good breakout role for him. It was different than all his preceding roles. It was like the first time he went out of the straight up comedy role. Right. And he did it. He accomplished it. He nailed it, in my opinion.

He was solid. Really? Like I was rooting for him. He worked for the IRS. He was an auditor. Who's the best comedian crossover to drama? accomplished it he nailed it in my opinion he was solid really like i was rooting for him he worked for the rs he was an auditor who's the best comedian crossover to drama yeah i mean short list right you got adam sandler you got jim carrey you've got adam sandler's the goat bro yeah he probably is he's the goat did mike myers ever cross over i think he tried to oh steve carell's actually done pretty well. Yeah. Anyways,

did you book your flight? I booked my flight. I booked my flight. We're booked, baby. Booked. All things open. All things open. 2024. 2024. Raleigh, North Carolina. Raleigh, North Carolina. I'm gonna repeat what you say. We'll be there. I think we'll be there. I can't see why we wouldn't be there. We're planning on being there. We're just not sure where our booth is at yet. We don't know where our booth is at, but we'll have a booth, right? We will have a booth. We will have options, I believe.

I think we have an option of in the main area near the ballrooms where we normally are. But where we have normally been is highly sought after. Right. And they had a swell of sponsorships in the end. I see. And so money trumps non-money. And I guess we're in the non-money bucket. We're non-money people.

Yeah. I would say we bring the money, but we're not given the money. I mean, we're so money that we don't even know it. That's right. But we don't actually have the money, so it's different. Yeah.

I get it. We'll be there, though. It's cool. We're flex. We'll have our microphones. We'll have stickers. Who knows what else we'll have i'm hoping we have at least one tv with clips yeah we'll have our clip gallery yeah behind us hopefully so if you're going to be at all things open 2024 which is at the end of october 27th through the 30th I believe is our official trip dates yes Sunday through Wednesday find us talk to us high five us Adam gives hugs if you're into that kind of thing sometimes I've

I've pulled back from the hugs oh you have yeah but I'll certain individuals depending upon how they look at me it's hug time how should one approach if they're interested in an adam hug great question oh geez i would say longingly and with a slight smile arms wide open or is that too much i would say come with a handshake and convert to hug right well that's the easy version like you you shake the hand and you lean in. Yeah. You can do the back pat and then you can be like, you can whisper in his ear.

I want the whole thing, you know, something like that. Give me the full hug. Okay. There you go. That's getting weird. But Hey,

if you do that, well, then you listen to the show and you follow orders or at least entertain our silliness. Yes. Who knows? So there we go. All things open 2024.

Also, our show with Alia Abbott has actually borne fruit, which is rare for us. We followed up Zulip. We're trying out Zulip in earnest, meaning we're actually using it, and we've invited people into it, and we got people in there, and we are checking it out. Now, I thought we'd talk about this on kaizen which is coming up just next week but

our kaizen is busted at the seams so why not just do quick first impressions here what we think about zulip after using it for two weeks ish maybe 10 days in earnest? You know, I did not expect me to like it as much as I like it. Really? I really was only trying it out of seemingly force. Like,

no one was forcing me, but I felt like we really had to. Well, we said we would. Well, yes, we did.

So, yes. But there's no force there. You can always make empty promises or at least empty words to some degree.

Uh-uh.uh well i don't mean to like not do it but i mean like i was begrudgingly trying it out let's just i know you were i felt it i felt your big grudge for a minute yeah because you're like you set it up you invited me and then you were like i could tell you're like and i'm i did my thing i did what i was supposed to do yeah yeah well i felt like i i'd at least done least done that, but what clinched it for me, and this is where we were chatting in our own DMs in there, was I was like, I really just feel like we need more realness to it. I can't just DM with you and be like, yeah, I like it. Let's do it. That's not going to be it. We or at least my judgment, my prejudgment. Sentiment. Yeah. Changing. There's people in there. And I would say there's more deep conversation in Zulip than has ever been in Slack. Now there's been lots of conversation, but like, it seems like

it's deeper and longer because the thread is there. The topic is there. I don't know. Something. Yeah. because the thread is there, the topic is there. I don't know, something uniquely different is in Zulu. And now when I go back to Slack, I really just feel like I have no idea where the conversation's at. Right. Yeah, a couple of things that have struck me. The first one is required topics makes you think a little more

before you do something or say something. And so there's a little more intentionality to what you have to do, which is friction, which sometimes stops you. It's like, I think you said it, this feels more like real-time email. And because when you start a new email thread with somebody, you have to put a subject in that email. And that's what a topic is, really. And so it does feel a little bit more like that compared to Slack.

The second thing is, and our community folks have figured this out quickly, it feels like it's built by nerds more so than Slack does, even though Slack has some nerdy things for sure in there. Nerds built this, and that's really cool. You can feel that love. And then the third thing is, we've already had a success story with one particular community member who already interacted with the Zulip team

and their dev channel and had influence on the way the product was being built. And that's the open source ethos that we love. We would never have that kind of access with Slack. We've known folks inside of Slack for years off and on, engineers. And we're like the smallest fish in that huge ocean of users.

So that's pretty cool. It has its problems. It has its warts. But yeah, kudos to the Zulip team for putting together something pretty cool. Yeah. And I think when you look at, like the first thing I start to think about when I evaluate something is the experience and the user interface, which is not simply just design. It's also experience.

I thought because, well, they're not venture backed, not that they're less talented. They've got less resources to apply to eke out all the UX permutations. And I really just thought it would be less polished. And that's not true. Like the built by nerds thing, the keyboard shortcuts is what's selling me. It's hard selling me. Like being able to navigate around. It's completely keyboard driven.

Like you can drive it without your mouse 100% if you want to, which is really cool. Which is why when I go back to Slack, I feel like I'm clicking everywhere and it's so fatiguing in comparison, like one-to-one going back and forth because we are straddling the line where we've got a micro version of our community in our Zolot and there's conversations happening,

there's topics, I feel like it's pretty fleshed out in a way, like it's on its way to being fully fleshed out. And then we're, we're going back to Slack for other conversations because we haven't made that cut over yet. And I'm not sure if we will, maybe we can talk about that here on this conversation, but I don't know the answer right now. Yeah. I mean, I kind of feel like I know the answer. What is it? I feel like it's, yeah. Like Zulu is the future. Okay. That's how I feel.

I feel like, so I didn't share this with you yet because I've been, you know me, I'm a reserved, I suppose. I haven't been talking a lot in there. I've been observing people, conversating and participating through observation and here and there jabbing in with some stuff. But the web public stuff is super interesting. I think it could be

cool to find ways to like make the change law community not so much bigger to be bigger, but this idea that I've always shared, and I think you've adopted it too, is this idea of no imposters here. Everyone's welcome. And that same idea where maybe Zulip, because we have this full history and we can self-host it and all the things, we're not locked into their cloud. We can begin there and move to our own self-hosted version of it. I feel like we have a lot more room to really lean even heavier into community where we could have before but we would have had to pay for it.

And it was very, you know, a significant cost in the Slack world where maybe we didn't put that kind of pressure on ourselves to do so because of our known limitations.

Whereas now I feel like unfettered. Now we can literally do what we want. And I don't know this to be true, but I can hypothesize that it would be that we can get pretty good buy- buying and support from Zolot. Yeah. In whatever ways. Like if we have ideas for how to make this

even more community focused, then I think that there's an opportunity there that was definitely not there with Slack. I agree with all of that. And I think that there's definitely ways where we could increase the amount of community discussion around the shows by deeply integrating into Zulip versus what we have been doing previously, which is some of the ideas being tossed around in our channel about, you know, sharing certain channels publicly

and allowing people to lurk. Yes., allowing people to lurk, sign up, integrating the actual comments of our episodes into that directly, the discussion. So yeah, there's a lot of opportunities for nerdery and tomfoolery that previously were kind of just, they were non-starters because you were just deepening a relationship with an entity that you really couldn't go deeper in any sort of communal way.

It was like, what are those barnacles on top of the whale? We like just a little bit bigger barnacle living off this whale. Well, we're not their customer either. We're not who they're optimizing for. No. And I don't think that, and so I suppose now that this thought has come into my mind in this moment, the only hesitation or reservation I have with Zulip is the uncertainty of their future,

which is not to say that I think their future is uncertain. Whereas Slack, maybe it's the same. I mean, geez, products die every day and they get deprecated. So, yeah,

exactly. Who knows? Even though they've got maybe more deeper pockets or... Way deeper. Yeah. Whatever.

I think my only concern with Zulip is that reservation of like, how will they persevere? I know the team is capable of doing it. Sure, but even if they don't, then it's a open source project that we self-host

and maybe we just don't go deeper than that. We just continue to use it as is. I mean, as is, it's got completely serviceable community chat, completely serviceable without any changes. Yeah, great point. Obviously, improvements always welcome. Well, I guess my reservation came

from the fact that while I know it's open source, I'm used to things like we're using in Slack not being open source. And so my brain hasn't said, okay, this is open source. So that reservation can be degraded down to 50% versus 100% reservation. Because that's super cool.

And that is, that's, I don't know if you listened to the show yet, but I monologued a little bit. I've been doing this a little bit lately in the end of our interview shows because I have thoughts and I just started calling it like closing thoughts and stuff.

Because I just got thoughts afterwards that I just like reveal. And this one in particular, I talked about potential. And I don't know if you've ever heard me describe potential as kinetic energy stored waiting to be released. Cause I feel like that's my reservation with, with Zulip is they have so much potential and it's not that they haven't achieved greatness by any means. I'm not trying to degrade or downplay the greatness they've done by any means,

but I believe they have so much more potential to potentially unseat, not so much fully unseat the giants like Slack or Teams. But when you look at the feature set that people really want, I feel like Zulip's got it. What they don't have, and we talked about this on the show,

was the awareness. Yeah. And something's got to change there. And that's where my uncertainty for them comes, is like, you've got to figure out how to market. You can't be the best unknown tool in the marketplace something's got to change there and i don't know if it's dollars spent but something's got to change with their their gtn their go-to market strategy how they talk about them their awareness firefox famously get firefox we've lamented on this in positive and negative ways

over the years. Like they did all that grassroots stuff with a very shoestring budget. Zulip can do something similar, I believe. And that's where my reservation comes is like they've got so much

kinetic energy stored waiting to be released, this potential. And I want to see them do that. Well, perhaps in the spirit of open source, we can also help them do that. I think our adoption would be useful in that sense.

Let's talk about some other things going on, of course, with open source companies. You're always afraid of a rug pull, as we've experienced many of holes, especially of late. How about this? I'm calling it the reverse rug pull, in which they, I don't know, put the rug back. Elastic.

Elastic search. Open source once again. How about this? Reverse rug pull. So cool. That might be going a bit far because it does imply that you have rug pulled in the past. So you were already not cool and now you're putting the rug back.

So I don't know if it's so cool, because the better thing is just like, leave the rug where it was. It really held the room together. Sure. That rug really tied the room together, did it not? But yes, much cooler than the rug pull. We don't want to talk too much about this, because we are talking with Shea Bannon, CTO of Elastic, soon, this month.

He's coming on interviews for the deep dive. But yeah, Elasticsearch opened back up again, went full OSI-approved AGPL license, and Shea's pretty excited, as you can just read into his announcement post from August the 29th. And we're excited too, right? I mean, you called it so cool, so you must be for this move. Well, it was just a saying.

I don't know if I have that belief yet. The jury is still out for me. So when I read his words, I can read between the lines and hear the sentiment of positivity. Like he seems to be very excited. Yeah. His roots in terms of how Elastic was born was Hacker. And I think I was reading over on InfoWorld from our friend of the show, I suppose, Matt Asay. Is that how you say his last name? It's either Asay or Acy. Acy. Matt ac ac matt ac and he i'm going to paraphrase but he talked about bannon's shea bannon's initiation of elastic was he personally paid for

the trademark for elastic to protect his work he was the the developer making it in an apartment i think in new york city and so very much like the stories we all hear about which i which is He was the developer making it in an apartment, I think, in New York City. And so very much like the stories we all hear about, which is why I'm kind of leaning back towards this so cool aspect. Because we all have dreams when we produce works in the world, our art. Sometimes it's code, sometimes it's pixels, sometimes it's both. And I believe that in a position which we may not have fully agreed with and we can argue and have argued and have done shows on with the Elastic versus AWS scenario, that you've got to do sometimes what you've got to do.

And we may not agree that, hey, let's now go closed source to protect. But I can at least respect their choice to do so. I may not agree with it, but I can at least respect that they've had the fortitude to do so. And now to be in a position, the same hacker that made it initially, when you read his post on it, you can tell he's excited. You can tell that he's got joy writing the words and revealing this and going back to an OSI

approved AGPL license. And at least there is now a trajectory now for a, as he says, more open source in the world. Yeah, I agree. Obviously we have questions, which is why we invited him on the show to talk.

One of the main things I want to ask him about is he asserts in his post that their move was successful. Like that was a successful thing they did despite him not wanting to do it. And now it's provided this opportunity to go back. And I would love to get that all out in the open. How did it find success? How do they know it's successful? Because we recently covered RedMonk's analysis of open source rug pulls and whether or not they've been worth it.

And to the best of her ability, I think it was Rachel Stevens over there at Red Monk, did the analysis on a bunch of at least publicly traded drug polls so that you can get the data. And she couldn't find any correlation between actually any sort of meteoric rise after the license change, especially ones that have been out there for a while, including Elastic. So that's an interesting thing. And we'll be talking with him soon to our listener.

If you have specific questions, lines of thought, conversation that you'd like us to broach with Elastic CTO Shea Bannon, definitely let us know. In Slack, in Zulip, I don't know. Email editors at changelog.com. It's probably the safest place right, unless you're already in our Slack or already in our Zulip,

then just go ahead and use what you're already doing. That works. I was just thinking as you were suggesting that, if they were going to pile on or start anew in Zulip, where would it happen at? That is the challenge, not to go back there, but that's the challenge, not to go back there, but that is the challenge of like, where does that live? Does it live in general under a topic called shows?

Does it live under change law podcast that isn't a channel yet that will be a channel soon? Right. Or interviews? Interviews. I think we are going to create one channel per podcast, as I've already started to do, where we publish new episode notifications for discussion, which I haven't created one for this show yet because we haven't shipped an episode yet, although today or tomorrow, I assume,

we'll have last week's going out. Yes, sir. With Ariz Zuckerman. In that case, I think you would just go to the changelog or interviews, I guess, and be like, questions for Shea Bannon, and you just start a topic called that. You don't have to post into an existing topic.

You can start a new topic. And it could be ephemeral. It doesn't have to be a long-lasting thing. Just post your conversation in there, and then Bob's your uncle. Bob is your uncle. That's my thought on the matter, at least. But yeah, you do have to stop and think

before you just start talking, don't you? And so that's the other challenge the matter at least but yeah you do have to stop and think before you just start talking don't you and so that's the other challenge with Zulip is I was my reservation came from like now everything has to be structured and then you have to be the person who says you're off topic or that thread or you know like they do in forums remember that when you'd be like slapped around

basically in forums like you're changing you know you're hijacking you know what I mean like well the cool thing about Zulip now we're turning into a walking advertisement I've already done this once forums like you're changing you know you're you're hijacking you know what i mean like yeah hijacking well the cool thing about zulip now we're turning into a walking advertisement i've already done this once you can just take an entire topic thread and move it to a different channel or messages that are on a topic you can just take that entire set of messages and move them to a different topic so instead of saying you're hijacking you just move them to where they

belong and people are happy to be like oh oh, okay, it's over here now. Yeah, cool. So that makes it somewhat less of a one-way door into more of a two-way door. How about this? Reverse rug pull. We'll see if it's cool. There you go. Yeah?

Yeah. And I guess we'll find out when we talk to Shea himself and release that episode and see how we feel about that because we'll see. Hey friends, I'm here with Brandon Fu, co-founder and CEO of Paragon. Paragon lets B2B SaaS companies ship native integrations to production in days with more than 130

pre-built connectors or configure your own custom integrations. So Brandon, talk to me about the friction developers feel with integrations, SSO, dealing with rate limits, retries, auth, all the things. Yeah, so there's a lot here and I think there's a lot of aspects to the different problems that you have to solve in the integration story in building these integrations and also providing them in a user-friendly way for your customers to self-serve and onboard and consume those integrations.

So part of what the Paragon SDK provides is that embedded user experience, again, what we call our Connect Portal. That's going to provide the authentication for your users to connect their accounts. That's going to be the initial onboarding. But in addition to that, your users may also want to configure different options or settings for their integrations.

A common example that we see for Salesforce or for CRM integrations in general is that your users may want to select some type of custom object mapping. Every CRM can be configured differently. So your users might want to map objects to some different type of record in their Salesforce or different fields in their Salesforce. And typically, that's what developers would have to build on their own is this UI for your users to configure these different settings for every single integration. That's also going to be what's provided by the Paragon SDK is not just that initial onboarding and authentication experience, but also the configuration end user UX for different settings like custom field mapping, selecting which types of features on your integration that your user might want to configure. And that's also going to be provided fully out of the box by Paragon SDK.

Okay, cool. That's the front of the house. That's the UI layer that developers are getting. So what about the back end, the rellimiting, the retries, et cetera? With integrations, different APIs might have different rate limits. They might have different policies that you have to conform with. And your developers typically have to learn these different nuances for every API and write code individually to conform to those different nuances. With Paragon, because we build and maintain the connector with each of the integrations that we support in our catalog, we're automatically going to

handle for things like retries, things like rate limits. For example, Paragon knows the rate limit for each provider and will automatically throttle your requests so that you can conform to the rate limit for those providers and be able to intelligently retry requests in the events that you exceed the rate limit for those providers and be able to intelligently retry requests in the event that you exceed the rate limit or a request fails. And so we look at this as sort of the backend or infrastructure layer of the integration problem that we have spent the last five years, essentially building and optimizing the Paragon infrastructure to act as the integration infrastructure for your application. Okay. Paragon is built for product management.

It's built for engineering. It's built for everybody. Ship hundreds of native integrations into your SaaS application in days. Or build your own custom connector with any API. Learn more at useparagon.com slash changelog. Again, useparagon.com slash change log. That's U-S-E-P-A-R-A-G-O-N dot com slash change log. Well, let's talk about another ChangeLog news item that I did not feature in audio. I actually think I just put it in the list of links at the bottom.

So I didn't write anything about it, but it's a really nice post by Christian Hollinger or Hollinger, perhaps why I still self host my servers and what I've learned recently. I thought this one would hit home with you, Adam, as a home labber, but maybe not a self hoster, but maybe a self hoster. This article is about two things. You, Adam, as a home labber, but maybe not a self-hoster, but maybe a self-hoster. This article is about two things, Christian says. Why I still bother and what has recently taught me.

Think of it as a brief retrospective and an encouragement for readers to go down the same rabbit hole. So Christian likes self-hosting and he thinks you should too. It's a long post, but to summarize the two reasons at least, independence, reason number one, and learning is good, reason number two. Are you convinced, Adam? I concur. It is a rabbit hole. I am convinced that you should at least attempt to do this. I don't think you should feel bad if you decide that it's not for you because it is a rabbit hole. It does require a certain level of responsibility over time, especially if your family or others around you begin to depend on those services and you can

no longer dedicate the time necessary to keep going. I suppose as long as you've got the time and the desire, then self-hosting is certainly fruitful. You will learn a lot. I learned a lot about many things that I just never had to really consider before. And I think that I'm a better conversationalist around technology because of it. And I think that I'm just generally more wise

to the tech in the world. Whereas before I had a once removed relationship with it where I would work with someone who was deeper in the knowledge and now I have firsthand knowledge. Yeah, 100% agree. I have self-hosted many things throughout my life and I learned so much doing so.

Both production and small business and friends and family stuff, whether it's self-hosted on machines in my house, which I have done for a long time. I had a Linux server that ran in my home, and I ran all kinds of services off of that. And then also VPS, self-hosting, shared hosting, self-hosting, you know, just managing your own things. And yeah, the amount of learning is really not to be compared with.

You can't fake it. You just, it's just real. But, but the learning comes through trial and it comes through things going wrong. And this post that he writes is like, here are the, one of the sections is like, things that broke in the last six months, you know? Yeah. And it's like, yeah, you're going to have that kind of stuff.

And it's similar to any sort of maintenance. I don't know how many large appliances and vehicles you own, Adam, but you and I are both old enough to know a house, a car, a laundry machine, anything that's significantly expensive and significantly complicated, brakes. And when you own it, you own the brake, you know? Yeah. And you're going to either pay to fix it or learn to fix it. And for me as a guy in my forties with a pretty large family, I don't have the patience or the time to self-host anymore, but I think everybody else should. Not everybody else, but you know, given your circumstance, I think everyone should try it and some people

should do it. And there's certainly things that I've thought about self-hosting, even though I don't have the time, because of privacy and autonomy and the independence that Christian speaks of. For me, more importantly than the learnings, I've already learned enough, I think, in the category, is there are things where I want the independence and the privacy. And so that's why I consider it, even though I don't want to do it, because I know how much of a headache it can be yeah I'm definitely not in the for me specifically Adam you must self-host all the things camp I'm not in that camp well I asked you to self-host Zulip and you were like you're on the show remember that no I was like I was not excited well it's just too critical I do self-hosting for the things that are, that I don't mind being down. If somebody's like, Adam, why is Zulip not working? That's the worst world for me ever. I don't want to live in that world.

I don't want to be responsible to that degree. I don't mind assisting. It's just not something I want to personally be responsible for. Nor do I think I have the expertise currently to do so. Well, you probably would earn it over time. I would earn it over time, but I'm like... Battle scars.

Yeah, I mean... And you get better at it, and it can become faster. Yeah. Because you're like, oh, I know what probably went wrong. Yeah. You know?

Confidence is there. I'm sure I could do it. It's not about lack of confidence. It's about lack of desire to hold the responsibility i would prefer zulip to run as zulip should run and be up for everyone all the time and it not be my problem so what are some things you're okay with hosting plex plex piehole stupid stuff you know my whole sounds like it's critical though it is but it's so easy to run well that's what you find out about

a lot of these things. They're very easy to run. Yes. And then you just got to make sure that they're updated or fix them. Getting it set up is the hard part. Right. They run while they run. Things go wrong here or there.

A network connection goes down. A time database gets out of sync. An update fails. Yeah. Usually for me, it's like, oh, critical vulnerability in this thing that you don't care about anymore. And it's like, oh, I have to go update right now even though three people are using this.

Like that kind of stuff. But most of the learning and most of the pain comes through that initial setup with the new technology. For sure. You know, this person's what is his name? Christian? Is that right? Yeah. Christian goes deep. You know, he is self, what is his name? Christian, is that right? Yeah. Christian goes deep. You know, he is self-hosting and he gives a list of things that he is self-hosting.

I'm trying to find a list quickly. To the top. My services, yes. Pile holes in there. Router OS. I won't read them all. Unify controllers in there. True NAS is in there. I think he even mentions he does it via Proxbox, which I would never do after trying it once. I don't like to virtualize a NAS

and virtualize the access to the disks. It's just too critical. So I feel like a dedicated box to your storage device is proper, even if it's overkill or a waste. You know it's done right right and you can pull the disc immediately if you need to and swap it and you know do some stuff with trunas to zfs or straight to zfs if that's all you have vs code i thought that was kind of interesting yeah vs code i guess it's like a web-based version of it or like how do you self-host Code? So, slight plug, I think they might be sponsoring this

episode too. And I'm not saying this because they sponsored it. I truly like their technology. Coder.com is so cool. I think it might be like this because Coder.com is a cloud development environment. So we've heard of this with like Codespaces, right? And Gitpod. Those are all

primarily Docker container based, where you're not running in a VM you're running in a container. And Coder.com does both but what they do uniquely is when you, I actually have a Coder.com instance in Proxmox so I dedicated a brand new VM

I created from Ubuntu made that the Coder box and now I can turn that into a cloud development environment. I can have code a new project, a new instance, like a new provision of a thing for me and my developers, which is just me because I was just tinkering with it. And inside of Coder, the reason I bring it up is not to plug them, is because whenever you launch the code, you launch VS Code, you can at least, you can launch V vim as well so it's for all the

hackers you can launch vs code in the browser and it will connect to the code on the vm in the browser like you're literally editing it like that i think that's what he's doing here is he's self-hosting similar to that but like it's the dedicated layer of just vs code where it's remote connecting to somehow the code on your local machine via the browser. Probably through the LAN. That's hardcore. That is so hardcore. I don't know why you would do that, but, you know, in the coder instance,

you do it because of resources. You want to take all those resources, CPU, RAM, GPU, whatever you need to dedicate to your environment into that CDE, that cloud development environment versus your local. One more layer. This is something I think is kind of cool is I have my Jekyll blog still yet. So adamsdokovic.com is a Jekyll blog, basically. I do not run that locally. I have set that up to run inside of Docker because I don't want to fiddle with Ruby and any of the gems and stuff like that locally. I have set that up to run inside of Docker. Cause I don't want to fiddle with Ruby and any of the gems and stuff like

that locally. Like it's all inside the Docker container, which I think is so cool. I never have to mess with local stuff. That is cool. I'm sure a lot of these services are Dockerized, which makes it a lot easier. Jellyfin for sure is.

Yeah. Yeah. But I mean, he's got Mariah DB running locally, Redis, Influx DB, Jellyfin, as you, yeah. But he's got MariahDB running locally, Redis, InfluxDB, Jellyfin as you mentioned, GitT, so he's like local Git server, local wiki, of course Nginx because his website and his blog are both hosted at, I assume this is his house.

This is like a homesteading version of software, right? He's a homesteader. You know, I'm glad you brought that up because i thought that whenever i saw his photo of his garden i was like self-hosting and gardening go hand in hand 100 right yeah autonomy man like leave me alone i'm gonna run my life but that's like if you're gardening then you're like i want to be self-sustaining right but then you're also tethered to technology because you're still self-hosting. So you're not, you're not like ejecting from the world, right?

You're not remote in Denver on a cliff or not Denver, like Colorado as a proper state on a cliff in the mountains, remote, you're still tethered to technology. Right. You're not living out in the boondocks of Montana. Right. I like Montana too. Yeah. What this looks like to me, and I don't want to be negative Nancy or negative Tim or pick your name by any means,

is if you're trying to be productive, this seems like a lot of yaks that could be shaved. On the daily, if you're self-hosting your local Git server, provided this is all routinely easily maintained, your VS Code is in the browser, you're maintaining whatever that is, and whatever can go wrong could go wrong, and you can fix it. But when it goes wrong, you've got to fix it.

Do you think that this is a list of shiny objects that can be distractions and or just simply things that need to be shaved like yaks? I don't know because nerds are going to nerd out. I feel like some of this stuff is probably him nerding out, which is totally fine to do. So in the case of that, like define productive, if this is what you enjoy, he obviously enjoys it. So it's almost like similar to gardening where if you don't love gardening, don't go plant a big garden because it's a whole bunch of work. And the people who continue and persist in that, they love the work. They love the process.

And so for them, that's what it's all about. And so, yeah, I mean, there's certainly some yak shaving going on. But, you know, if you enjoy shaving yaks, you get a yak, don't talk back. I don't know. I just got stuck on yak there. But go ahead. Christian closes with this, which might be a good end cap to our discussion. He says, if you're a software engineer, I recommend self-hosting things.

You learn a whole bunch of things through forced exposure to problems that you'll be less likely to encounter in your day job, which in itself is a benefit. Even better, I do believe you'll wind up using at least some of these things in your day job eventually, provided you work on something vaguely backend related. By hosting stuff yourself, you also get a reasonable level of autonomy or at the very least some hedging against the corporate dream of your entire life being a perpetually rented subscription. I think that's nice. Poetic. Good ender. I mean, it's certainly romantic. That part gets me. That does get me. Not enough to do it, but enough to appreciate it.

That's where I'm at. Because he mentions NextCloud in one of his services. I don't want to be, I mean, maybe I do at some point, but I don't, at least right now, I don't want to be responsible for calendars being up, photos being up, file services being up. I mean, it just seems like, oof. But maybe NextCloud makes it easy. I just feel like in the moment, without having tried it, it feels like a lot.

And I speak to that because of the rented subscription. Right. The easiest place you spend money is like Dropbox. Calendar, I guess, comes with our Google Suite for our business. And in other cases, you're getting it for... Or iCloud, if getting it for iCloud. If you have an iCloud account. Yeah.

So you're, you are on this, you will own nothing and be happy, you know, world forum or economic forum prediction several years back where it's like, someone famously said an infancy, maybe even infamously said you will own nothing and be happy. I just don't know about that.

Like the perpetual, it feels like a long-term debt that society puts on you. Like to own an iPhone, you kind of inherit a level of perceived debt, necessary cost to maintain the service. Yeah. Not just the phone service itself,

but the things that come with it to use it like photos. I don't know if that's the right word, but I'm with you in spirit. I think that. Well, it's dead if you, what I mean by the reason why I say that you have to pay back is that you, you commit to a payment. Oh, you're renting. Right. You're indebted to pay for the service if you use the service.

Yes. You have to pay for the service if you use the service. And if you stop paying for the service, then the service goes away. Right. And I think renting is totally reasonable in certain cases. Yes, you have to pay for the service. If you use the service and if you stop paying for the service, then the service goes away. And I think renting is totally reasonable in certain cases. I don't want to own a calendar service. I want to rent one. Because the calendar is only important over the next month, weeks,

and maybe years. But have you ever considered about your historic calendar? I couldn't care less what was on there. Every once in a while you go back and like, what day was that? And you check an event and you're like, oh, I didn't put it in the calendar. And you're like, dang it. Yeah. But if it's in there, it's kind of useful, but your past calendar events, I couldn't possibly care less. Rent that service. If it goes away, it goes away. Other things, photos, opposite, right? Like the history is what it's all about with photos.

That's the kind of stuff that I'm afraid to self-host. Availability and history and reliability that it's there forever. Deletion of photos is very, very bad. Yeah. All right, let's move on to our final topic. So you know how we take episode requests. Do we? Yeah, man.

Oh, that's so cool. It just takes a while sometimes. Is it at changelog.com slash request? That's right. Oh, gosh, that's a great URL. I love that. That is really nice. Well, we read every request,

and we don't fulfill every request, but every once in a while, we dig one out of the ashes and we would fulfill it three years later so shout out to listener alex if you're still out there if you're still listening alex three years later you're a trooper man we appreciate you because that's a long time to listen to and you should be in zulu anything and you should finally be happy that we've answered your request this one's navelgazy and self-serving to a certain degree, which is why we didn't do it for a long time,

but I thought it'd be a nice end cap to a Friends episode with just the two of us where we can take at least one listener question slash request. Alex wants us to talk about how we podcast. How we produce podcasts. He said he's heard of some really cool workflows from both the Linux people and you guys, which I guess means we're not Linux people, about different ways you record and upload scripts.

He says, you guys, if I recall, have some type of encoded timestamps to the MP3s. Destination Linux timestamped the episode while they record. Jupyter Broadcasting uses some type of all-in-one container for recording if he recalls. And we have MasterFeeds. They also have MasterFeeds. So just some of the inside baseball on how we produce our shows. Maybe some of the nerdier parts.

I don't know. Some of it's boring, at least to us because we do it, but maybe interesting to other people. I think it's boring, at least to us, because we do it, but maybe interesting to other people. I think it's super interesting to other people because I've been having some conversations with a future branded podcast we're producing. Oh, yeah. And they have questions and I have answers and they sit back and listen as if we have pulled up a glass of favorite drink

near a campfire and it's just so fun. Seriously. I didn't think what we'd done so fun seriously i didn't think what we'd done really yeah i didn't think what we've done is uh you know you don't know what you what you know until you try and teach other people basically right you know and then they're like wow i mean to us it's logical and simple because we've repeated it so many times that and refined it right we could probably do a lot of what we do to some degree in our sleep. Right. You know, figurative speech. Figurative speech, of course.

I swear I'm not sleeping right now. Not literally in my sleep, but for example, I'll give you an example. And this is not necessarily answering Alex's question, except for maybe to flex a little bit, and I'm not a flexer. I wrapped up this conversation yesterday for this Future Brained podcast that I'm not sure I can mention yet, which was why I'm being vague.

And the idea was, okay, we've got the music components together, and they can't hear slash see the future vision that I can see coming because I've got the experience and we've got the experience, and I know where we're trying to take them. They haven't done that yet, and so they have questions and reservations and apprehensions that need to be resolved. And the easiest way to do that is to give them a version, a listenable version of it. And so yesterday within the span of an hour and a half, I think I sat down and produced a fake episode that uses the intro music and the timing.

I script-writed the intro and how I think it should work, how it blends into the show, how the show ends and how the music comes back in, how the show could end. And I used all the components that we've produced for them and gave them three different versions because we have three different outros they're considering. The intro is solid and it's not being scrutinized in any regard but the outro is like they've got

questions of how it should should they be the same should they match up how similar should they be and you know doneness is the enemy of perfection right if you if you can't just get it out there it's gonna what perfection is the enemy of doneness i said that backwards you can't strive for perfection you can obviously you know don't wait until it's perfect or seemingly perfect or all the answers were answered to get momentum and move the reason i'm saying the story is that in the span of you know an hour i solidified and created what has been in my mind for for many months waiting to take action on when the time is right. And it's done. And I think when you listen to it, you'll be like, yeah,

that's a pretty good version of what it's going to be. It's obviously four minutes, not 40 minutes, like it might be or will be. It's a micro version, listenable, that's actually kind of compelling. And when I listened back to it, I was like, I kind of want to listen to the whole thing now. And it's just a fake. It's just episode zero. It's not a teaser. Yeah. There's nothing.

Well, there's something in there. Well, but not yet. If I told you, I would reveal too much. Sure. But I was like, yeah, I would listen to this. This is cool. And the reason why I say that is because we've done it so much that in the span of an hour-ish,

I created what is likely to be the future of that. Not two days or several days and had to go back and forth. It was just done. You're just inventing the future right in front of their eyes. That's right. Or their ears. That's right. All right, good, solid flex.

Stay tuned for a branded podcast upcoming of Adam's design with a partner, which will be the second time we've accomplished such. We do produce Big Tent, Grafana's Big Tent with them, which is the first one. And selective, but open to that process with others, very selective strategically because we're a small team

but to more directly answer Alex's question maybe he's interested in tools, techniques like how we do what we do and what we use he's not interested in my flex, he's like Adam just be quiet let Jared tell the true story we're going to chapter that one Adam flexes and then we'll have the the real answer jared answers alex directly is the

next chapter 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 cdeE, 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 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 uh 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 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. And I'm also here with Todd Kaufman, CEO of TestDouble. TestDouble.com.

You may know TestDouble from our good friend, Justin Searles. So, Todd, on your homepage, I see an awesome quote from Eileen Nucatel. She says, quote, hot take. Just have Test Double build all your stuff, end quote. We did not pay Eileen for that quote, to be clear, but we do very much appreciate her sharing it. Yeah, we had the great fortune to work with Eileen and Aaron Patterson on the upgrade of GitHub's Ruby Rails framework. And that's a relatively complex problem. It's a very large system.

There's a lot of engineers actively working on it at the same time that we were performing that upgrade. So being able to collaborate with them, achieve the outcome of getting them upgraded to the latest and greatest Ruby on Rails that has all of the security patches and everything that you would expect of the more modern versions of the framework

while still not holding their business back from delivering features, we felt was a pretty significant accomplishment. And it's great to work with someone like Eileen and Aaron, because we obviously learned a lot. We were able to collaborate effectively with them, but to hear that they were delighted by the outcome as well is very humbling for sure. Take me one layer deeper on this engagement. How many folks did you apply to this engagement? What was the objective? What did you do, etc.? Yeah, I think we had between two and four people at any phase of the engagement. So we tend to run with relatively small teams. We do believe smaller teams tend to be more efficient and more

productive. So wherever possible, we try to get by with as few people as we can. This was a fairly clear set of expectations. We wanted to get to Rails, I believe 5.2 at the time and Ruby like 2.5. Don't hold me to those numbers, but we had clear expectations at the outset. So from there, it was just a matter of figuring out the process that we were going to pursue to get these upgrades that we think is very consistent in allowing Rails upgrades to be done without like providing a lot of risk to the client. So there's not a fear that, hey, we've missed something or, you know, this thing's going to fall over under scale. We do it very incrementally so that the team can, like I said, keep working on feature delivery without being impacted, but also so that we are very certain that we've covered all the bases and really got the system to a state where it's functionally equivalent to the last version, just on a newer version of Rails and Ruby.

Very cool, Todd. I love it. Find out more about Test Double's software investment problem solvers at testdouble.com. That's testdouble.com, T-E-S-T-D-O-U-B-L-E.com. I do have a propensity to answer questions directly, which some people appreciate and others think is boring. So your mileage may vary. But in brief, okay, so tools and techniques. We record everything on Riverside.fm, which is a proprietary in-browser technology that we pay for as a service. Happy to rent it.

Don't want to self-host it. I'm sure it's very complex. And very cool use of web tech. And it's gotten better, continues to get better. We've been on it for at least a couple of years now. Very few incidents, so we're happy with the software. We own a separate account for each of our podcasts, and everybody logs into their own account,

they record in there. And that handles the majority of the actual video and audio recording and syncing. And then we export out of there into Adobe Audition for editing. We have kind of a three-step process in our editing. One's called prepped. So we prep the audio. This has to do with making sure all the tracks line up, all the boring stuff that people don't ever think about. Sometimes prepping the sounds, trying to get a different version

in case the audio of a specific track isn't great. And then we edit it, content edit. This is usually our editors. Shout out to Jason and Brian who content edit our shows. And their job is to basically cut out all the bad parts, which is just awkwardness, weird pauses, et cetera. They do their work. Ums and ahs.

At that point, they leave markers. So Alex asked about timestamps and chapters and all that. We don't do any timestamping or markering while we record. Seems like the ideal time to do it, but actually when you're in the moment, in the groove, you're not actually thinking about, oh, this great except for earlier when i said here's a chapter yeah every once in a while i'll think about it but you just want to be able to just be free from all that and just enjoy the conversation so we aren't doing anything i

think riverside has oh yeah they have a mark clip button right there that we could use to like set a marker but we don't do that sometimes there are things that we know about, and so we'll just tell our editors afterwards, like, hey, look out for this. You can drop a marker here, a marker there in our locals as we go. And I've done less of that than I used to. I used to do it more. But Jason and Brian take good care of us, so they handle the edit, then they pass it back to us for mastering,

which is all the final stuff. Chapters, ads, voiceovers, music, final edit decisions if there's any content editing to do. All of this is in just big old Dropbox folder, basically. That's organized by show and by episode and separate Adobe Audition sessions for each phase. So very much a manual version control system that works just fine just by copying files and renaming them. And then we mix down a WAV file and an MP3 file and we upload them to our website.

Hit publish, baby. Now that's both detailed and glossing a bunch of stuff, right? Yes. Yeah, the cool thing about the way that Adobe Audition works is that you have a file type called.sesx. And those files point to a local file set, essentially. It's like a timeline. I imagine it's probably, I've never actually read the file type. I thought it was proprietary.

It's like an XML file, I think. It's very XML-like, yeah. Yeah. And so when you make these copies of it, the file is like a couple megs at most. So like, for example, Jared mentioned the prepped version of it. So we have a show coming up today on these ergonomic, really awesome keyboards from ZSA. And the prepped file is 130 kilobytes. The edited version is 2.2 megabytes.

And because the master version only has a couple things added to it, it's the same file size. Now, once those changes go in, I'm going to produce that right after the show or after this recording that we're literally talking into right now. I'm going to go do that work in the master file.

And that file size will grow probably to, at most, three megabytes. So like these session files are very small and are supported by the local file system, which has recorded sessions in their imported files, all these different things that are sort of like file system stuff that Adobe Audition uses. Adobe Audition has been really good to use, I would say, over the years because it moves from person to person pretty easily as an independent file system

or an independent directory that you can copy and do whatever you need to do with it. And so we've been very happy on that front. And even chaptering within in the wave file, when we do that, there's a span that you can put like a marker and another marker and join those together and make them a chapter or a two point marker. I'm not even sure what they call those things, honestly,

merged markers, something like that. And let's turn it into chapters. Range. Range marker, I think. Yeah. Been very easy to do that

and i think it's important probably jared for you to talk about some of the stuff you're doing with the wave file can i interview you a little bit sure on this on this process i feel like maybe they they might get more mileage on on an interview version versus a monologue version of it absolutely so i know what we do we we mix down a WAV file. Right. And then we mix down through a process called match loudness to get to the MP3 because there's some things that happen in this match loudness process that make it broadcast worthy. It kind of pulls levels up inside the MP3 file to make it, you know, the levels normalized and stuff like that for production audio out in the world. And so the WAV file has chapters in it. It's larger than the MP3. We then drag that WAV file into match loudness and push go essentially,

or run I think is the word for the process. And then a minute or two later, depending upon the machine you're using it on, out comes this MP3, right? And so we upload the MP3 into into our cms our website our application and then before that though we also sort of drag and drop this wave file can you talk about what you do to introspect that wave file to pull out the chapters to pull it into the cms and then some things that happen with the mp3 when it comes to like date changes or title changes or slug changes, how those things permeate into the final CDN that actually goes out to the world.

Right. So there's really two sources of truth for any piece of information about an episode. And those two sources are the RSS feed or feeds in our case, in which the episode lives, and then the ID3 tags inside of the MP3, the final artifact. And those two sources of truth should be synchronized and match. And so the obvious place to do that work is in our admin, because our admin is where we author a lot of that information, including the title, the date published, the duration. We pull that out of the MP3, but all the information is stored in our CMS. And so the way that the chaptering works, and really the way that all metadata works,

is every time you save that episode in our admin, it's taking the result of the episode information that's in our database, it's rewriting a of the episode information that's in our database. It's rewriting a brand new MP3 that has that exact same match data. So it's always the same. The MP3 does not contain the chapter information until our admin contains the chapter information for that same reason. The chapters need to be outside of the MP3 because they also have to be in the RSS feed. We also use them on the website. We use them in multiple places.

And so the data has to be outside of that MP3. And so the way that we get that is out of the WAV file. So the MP3 gets uploaded into our admin. The WAV file is huge in comparison. MP3s range from 50 megs. Well, ChangeLog News is like 7 megabytes. Anywhere from 10 megabytes to 100 megabytes, sometimes bigger for Adam's epic interviews.

But the WAV files, that's raw audio, uncompressed. And so we're talking gigabytes, right? So we don't actually want to upload the WAV file to our admin. We just want the information out of it. And so every episode post audition has four artifacts, two WAV files, two MP3 files, one for regular changelog people. And then the it's better folks get their own file. It's better. That's right. For plus plus. When you drag the WAV file into our admin, it's just dropping it into the local browser session. It's not uploading it to the server.

And the browser via our good friend JavaScript uses, I can't remember what library we're using, wave.js or something. Something somebody else wrote to basically introspect the wave file, which can get at the markers, pull them out, match the timestamps, and basically create for us a bunch of chapter objects in the form.

And that's how that works. So the WAV file is then discarded. When you hit save, the WAV file is not going anywhere. It just disappears. MP3 gets uploaded along with the chapter information. And the chapter information can live in the admin episode before the MP3 does. Yep. Right?

Because it's its own data set, basically, which informs the RSS feed. That's right. And you can go back and edit it later, and it will reflect into the MP3 and into the RSS feeds. And so that's why I want that to be the source of truth

versus the WAV file. The WAV file is kind of like a starter for your chapters, basically. Right. It's the... Starter's a good word, I suppose. I was trying to go with a different word. The kindling.

The initial vehicle to get it there. I don't know. The transport layer. Yeah, it's just like the baseline data set. It's actually the conduit between Audition and Web. Yeah. Right? And you could completely ignore it.

You could author all your chapters by hand in our admin by hitting add chapter, start time, end time. You could do that if you're a fool, but we're not fools. No, and so the cool thing too is to kind of go technically a couple layers into the details, the WAV file does not get uploaded, as you mentioned. It infers and informs the admin of all the chapter data. And the cool thing I think of is afterwards, if there's a typo,

which I will go and save and then preview the webpage, because sometimes in Audition, it's not easy to see all those typos because the interface of Audition has small type. And I'm in my forties, as you've alluded to you being in your 40s. Yes. It's not that my vision is bad. It's just, you know, it's small. And so I'll see things differently when previewing it as the, you know, future episode page of this episode, for example. And I'll notice that I fat fingered something or whatever may have happened, and I will change it in the admin versus having to re-upload a new

WAV file. Now that does mean that the wave file is no longer the source of truth, which is obvious because it's not meant to be, but the change happens in the web, not in the MP3 or sorry, the wave file, which can take minutes, sometimes 15 minutes if you're on a non-Apple Silicon Mac. Yeah, too long. Like I've learned, you know, it could take, you know, 10 minutes sometimes to mix down from the session into the WAV file. Yes. And so that could be too long, like running tests, just too long. Forget it. Right.

Just do it in the browser. And sometimes you'll catch a typo on an episode that you're listening to a week and a half later. Maybe Adam mastered it. So it's not even on my machine. Like Dropbox hasn't synced it i don't want to go sync his session down remix it down etc so i just go into our admin make the change and we're good to go so that's really cool all the mp3 chaptering abilities shout out to our friend losch vickman who we hired a couple years ago to write a Elixir library, which allows

us to write ID3 v2.3 tags, which we couldn't previously do with our FFmpeg-based solution, which is why we didn't do chapters as quickly as we wanted to. All of that you can find in old episodes. There's a Kaizen with Losh. There's also an episode that I thought was really fun called A Guided Tour Through ID3 Esoterica, where we talk about all the cool stuff Losh learned along the way as he wrote that library, which we now maintain, although it's had very few changes because it works pretty much as advertised.

Over the years, it allows us to embed images and links as well. Super cool. And, you know, not to flex or anything, but I feel like we have the best chaptering game in the biz. That is a flex, isn't it? Flex as you'd like. I concur and I agree. Our chapters are pretty on point.

I'm such a chapter snob now, man, really. I feel like anybody who's an avid podcast listener listening to podcasts that don't have chapters or haven't appreciated or come to appreciate chapters in podcasts are missing out so deeply. And maybe it's just because, you know, we're professionals and we quality assurance our stuff that I want to jump around more than the other listeners. Cause like there's a lot of listeners, like I don't jump around the podcast.

So I have no need for straight through. And then they move on to their next episode and some other show. Yeah. But I'm like, I kind of want to just jump to that one spot, especially when the chapters are so well named, you know, so,

so much care and love. But for me, that's the fun part is yes, we get to inject a lot of fun, you know, really, I wouldn't call them easter eggs but like the the fun is in the chapter names and sometimes the chapter metadata that like i know seven people are going to notice or or less but someone's going to notice and get a giggle hopefully or even just roll their eyes. But yeah, chaptering is something that we really take seriously and put a lot into and I guess don't care so much

that a lot of people get a lot out of it. We'd love more people to. But it's kind of like that thing with Steve Jobs and Johnny Ives where they were designing the inside of a thing or the back and they didn't care if nobody else saw how cool it looked on the inside because they knew they knew how cool it looked so that's how we do chapters it's probably the most technical and interesting part of our flow everything else is relatively bog standard yes i think the chaptering is the is the bee's knees man it's the cat's pajamas it's the good stuff and i think our workflow affords us the ability to do that with such care.

Because in the, you know, going back to when we marker, taking the time in that post-production process took a bit to get used to because it is a time slot. You got to dedicate to it. You know, you may dedicate more. I may dedicate less. You may dedicate less. you may dedicate more I may dedicate less you may dedicate less I may dedicate more who knows but I

you know doing that pass is like the final I would just say like chef's kiss moment opportunity on a show

and maybe we we take too much we take it too seriously and others take it less seriously like you just mentioned with Steve and Waz like designing the inside

of this thing that nobody gets to see but they know how cool it looks I feel like that's the cool stuff for us there was a couple chapters I can't get to them

that I can think of I don't know I was gonna I was gonna like bring out one from a recent show but like it's so contextually

adjacent from this conversation it won't really translate well but if you go dear listener and you go through even like Lady Bird, like that episode, episode 604 has 42 chapters. That's a lot. And the final chapter 42 is an awesome number two,

by the way. That's true. The final chapter is cozy lo-fi from Caitlin Colt. Because Andreas' wife produces lo-fi music that you probably could listen to when you're coding on YouTube. Good stuff, too. I've been listening to it. Have you? Mm-hmm.

And that was his plug. And so we decided to put, I think it's actually called Cozy Lo-Fi is the name of that track. And so we put that in there as its own chapter dedicated. You can just jump to that chapter right now and listen to it. To me, that's the cool stuff. It's the details in podcasting that really... And I would just say,

Marco, if you're listening, I love your software for the most part, but this latest update to Overcast, I am not super happy with it. I want to take this moment to tell you that chapters are so cool and the way chapters work now is not so cool in Overcast. I liked it so much better when I clicked on a chapter,

the page didn't go away. And now you have to go back to it again and find where you were at before you can use it as a jumper. Like a table of contents that did not move when you moved around. The audio would move because it's audio, but the interface did not hide. The chapters are a leaf page that pop up, and as soon as you click on one, it goes away.

And then when you click on it again, it doesn't even take you to where you're at in the chapter list. It takes you to the top. And so you've got to scroll, scroll, scroll to where you're trying to be at. And so the experience of chapters has drastically changed, in my and i'm super sad please change it marco if you're listening a plea from one particular user and if not we'll just chapter this in the audio and link directly to this chapter and send it to you there you go so one quick chaptering story before we move on as we're just stuck on chapters.

This chapter will never end. A recent JS Party episode is called a Nick-level emergency. So Nick Nisi, whom you may know from JS Party and also from Changelog and Friends and other changeloggy goodness, is a big TypeScript fan. And the Node.js people recently added some TypeScript-related features, and Nick wanted to have an emergency pod about it. It was not worthy of an emergency, and so we did it anyways.

We made fun of him along the way, and we called a Nick-level emergency. That's JS Party number 333, which is a fun ride of itself. But then I got this idea for the chapters. Since this whole thing was Nick's emergency, I'm going to have him referenced in every single chapter. And so there's 22 chapters on that episode, and if you go read them,

every single chapter has the word Nick in it somewhere. Chapter 3, Node adds TypeScript stripping for Nick. Chapter 4, Nick would absolutely love this. Chapter 5, Nick, I'd rather be TypeScripting. You get the point. That's the kind of nerdery I'm talking about. Why not, right? Have some fun.

Probably less than 7 people realize this. Less than 7%, huh? You think so? Well, how do you know? How do you know how many people will look at your chapters? We need to chapter pixel tracking technology ASAP. Yeah, I do appreciate that level of detail that we can put into it, which I believe the hardest core of hardcore listeners do appreciate. Just imagine the experience of hearing about us for, you know,

the second or third time, and maybe you're not a full-time listener, but you've been linked up to an episode page and you land there and somebody says they talked about X and pick your variable, right? They talked about, you know, Nick level emergencies on this thing. And he was mentioning his desire for what's new in ECMAScript 24. You can jump right to that chapter. And that chapter is also a linked chapter that goes out to an entire article on the news stack about it, because that's probably what Nick did in the show notes was like, hey, this is what my reference point is. So they can go right to minute 18 and 26 seconds and listen to what's

new. So when they come there, they kind of get this version of instant gratification. Whereas podcasts generally require you to dedicate, in this case, 51 minutes potentially to hunt for the goodness. Chapters point you directly there. Now I mentioned initially chapter snob. That's me Even on youtube like if i'm listening if i'm watching anything on youtube like a recipe, you know, i've been like all in this chef stuff, you know If I find a video that's like next level Chicken parmesan and I want to like examine their recipe I don't need to know

Like if i've experienced, I could chapters, let me bypass the things that are not for me versus having to listen to the whole thing or watch the whole thing or whatever it might be. Like if you are on YouTube or you're podcasting like we are, and you're not chaptering and you have anything that's more than five minutes, sad, man. Like I will just bail on it. Like, I'm just not going to give your content time because you have not respected my time. So here's a feature for YouTube I've been thinking about. Because we do now allow YouTube to slurp in our audio episodes.

And you can subscribe to JS Party, GoTime, what have you, on YouTube via the playlist at youtube.com slash changelog. And so this is YouTube's official way of adding audio podcasts as a feature to their platform. And they re-host like Spotify does, but they do not respect chapters in your feed or in your MP3 or anything like that. And so we do not have chapters on youtube whereas we did go out of our way and implement spotify's specific requirements for

chapters on their platform we do not have them on youtube what i'm thinking about doing is creating a second feed for every one of our podcast proppers that includes the chapters as timestamps in the show notes, which is how YouTube works as a creator. The way you add chapters in YouTube is super lame and manual. It's probably actually a good solution for non-technical people because

you basically just put a section of your description, a list of timestamps with a title, and it will turn those into the chapters inside YouTube. That's how it officially works. There's no chaptering functionality in there, YouTube Studio. You just put it in the description, and it turns those into chapters. And so I might start writing for every one of our podcasts

a second feed file that's just for YouTube and point YouTube at that one, and everything is going to be completely identical except for we put the chapters in the show notes as timestamps. And that would give us chapters on YouTube. I don't want to do that in our feeds generally because it bloats them quite a bit. And our feeds are already pretty bloated due to being complete episode

catalogs versus like the last 100 episodes. So our feed files are already pretty large, but that's something I've been thinking about doing for YouTube just to get the chapters information out to YouTube. episode catalogs versus the last 100 episodes. So our feed files are already pretty large, but that's something I've been thinking about doing for YouTube, just to get the chapter's information out to YouTube. However, there's just not that many people listening on YouTube yet, or maybe ever, because we're a non-video podcast. A good episode, I think most recent Changelog News outperformed,

and it was only a couple days ago, 500 people listened to that on YouTube. Typically we get a hundred ish per episode over there, but I think having chapters over there would be appreciated. So I'm thinking about doing that. Haven't done it yet. Now we're, we're basically Kaizen-ing. So maybe we should stop. Well,

there's a little Kaizen in all the conversations, you know, you're always part of Kaizen is always be improving. That's always, you know, that's right. Improve without ceasing. All what's left i would say what is left is just to thank everyone who is paying attention to this enough to care about this last how we produce podcast section maybe you don't care maybe you do care maybe you care about how we maybe you got some ideas maybe like man have like, man, have you tried this?

Or I like that workflow, but what about that? Our stack is open source. And I would say open to contributions. There is a Zulu for that. Or a Slack for that potentially, where maybe you can hop in there into a dev channel. And if you've got some ideas, obviously it's open source.

You can fork it and do what you want, but you can contribute. You can leverage the code base to learn. I was going to ask you some questions about the RSS feed because I think over the years you've iterated to what I would probably say is potentially the best RSS feed alive. With all the necessary features, you're really good at being on the tip of the RSS feature list where what should be and could be supported is supported.

You know, almost, I wouldn't say instantaneously, but pretty close to instant whenever it makes sense. And so I think RSS feeds are pretty solid. So much so that I actually pulled down the master feed and I have it opened up in Zed just to look at a raw RSS

feed from the master feed, which is just humongous. It's like 12 megs. I'll tell you, I curled it down. It is 11.7 megs. Oh, I drilled it. And it took me three seconds

to curl it down. That's a pretty long time for an XML file. I mean, that's... 12 megabytes. It should be almost instant, right? Not for 12 megs. Eh, I suppose.

I mean, an XML file is not usually that big, though. That's a pretty big XML file. It is. It's got over 1,000 episodes in there. Yeah. But it's got a lot of cool stuff in there. So all that to say is our code base is open source. If you're curious on how these things are implemented,

look at that. Obviously, we are still in the process of potentially fully adopting Zulip, so there may be a place for you to have a conversation if you want to contribute so you can hop in there and share some of your ideas of course or just fork and do and and pr away there you go but yeah it's been fun to talk about self-hosting and the the non-cool cool rug pulls that are reversed and stuff i'm excited about that stuff. All right, that's all we got for this week. Thanks for hanging out with us.

Coming soon to a friend's near you, Kaizen. Coming soon to a friend's near you, Natalie Pisonovich, talking AI code editors. Coming soon to the changelog, Elasticsearch. What else is coming soon on the changelog, Elasticsearch. What else is coming soon on the changelog? Oh, coming soon on the changelog, Jimmy Miller talking about the best, worst code base. That should be good.

Yeah, yeah, yeah. Looking forward to that one. So stay tuned right here. And if you're a nerd and you like pretty things, go curl down our RSS files and just appreciate that formatting because, you know, it's a lot of hard work

putting in those suckers and nobody reads them but computers. Yeah, chapter data's in there. All the stuff, it's a lot of stuff in there. Very cool. It is hard to appreciate that stuff. And I would say one more back in your list,

because this came out after that is ergonomic keyboards from ZSA. Cool stuff. That's right. Scroll up, hit play. That's right. Or down, depending upon where I'm looking forward to that episode.

Although I'm looking back at it as we publish. Yes. The time travel of out of sync podcast recordings. All right. Let's call it a show. See you all in the next one. Bye friends. Bye friends.

Change log plus plus members. Stay tuned for an even deeper dive into our RSS feeds and how I rewrote all the XML rendering in our app, mostly because I didn't like the way it looked. It's better. And don't forget, it is still September, so you still have time to trade a five-star review for free Changelog stickers. Write up a thoughtful review or blog post, send proof to stickers at changelog.com, and we'll mail the goods directly to

your front door. That sounds good. I'll have that. Thanks again to our sponsors, Sentry, Paragon, Coder.com, and Test Double.

And of course to our longtime partners at fly.io. To our beat freaking residents, the GOAT, Breakmaster Cylinder. Yeah, music's good. And to you for listening, we GOAT, Breakmaster Cylinder. Yeah, music's good. And to you for listening, we appreciate you spending time with us each week. Next week on The Changelog, news on Monday,

Jimmy Miller tells us about his best, worst codebase. On Wednesday, and Gerhard Lazu joins us for Kaizen 16 on Friday. Have a great weekend. Leave us a five-star review if you want some stickers. And let's talk again real soon. So Jared, is there anything else we could talk about with this RSS feed? It's, let me count the lines. Let me count the lines. Let me count the ways. 88,724 lines

is the length of the LOCs on this file. Well, that's our entire episode history in a single file. So that's kind of interesting to think about. That is the changelog. In a nutshell. Literally is.

It is. Everything that we've done is in there. It's better.