The Changelog: Software Development, Open Source
Reverse rug pull, so cool? (Friends)
Fri, 13 Sep 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. 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 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 debug ability 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 debug ability 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 our code CHANGELOG. Get $100 off the team plan. That's almost four months free for you to try out Sentry. Once again, Sentry.io.
The only Bob Seger song I could name is Old Time Rock and Roll. That's like the worst one. 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. I 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? No.
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. Well, they had 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. Like 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. Okay. I think it's 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, 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 then? 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? 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 crossover? 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.
2024.
2024. Raleigh, North Carolina.
Raleigh, North Carolina. I'm going to 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.
I would say we bring the money but we're not given the money I mean we are 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 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 pulled back from the hugs.
Oh, you have?
Yeah. But 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. 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 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, Adam. Yeah. 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. Like we've actually, 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.
Well, I don't mean to like not do it, but I mean like I was begrudgingly trying it out. I know you were.
I felt it. I felt your begrudge for a minute.
Yeah.
Because you're like, you set it up, you invited me, and then you were like, I can tell you're like, and I did my thing. I did what I was supposed to do.
Yeah. Yeah. Well, I felt like I had at least done that. But, you know, 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. You know, we've got to have some real stuff in there.
And wow, in addition to my mind changing or at least my judgment, my prejudgment. Sentiment.
Yeah. 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. Something uniquely different is in Zulip.
And now when I go back to Slack, I really just feel like, 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 while 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 nurse 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 a hundred percent 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. Right.
Where we've got a micro version of our community in our Zoloft and there's conversations happening, there's topics, there's like, I feel like it's pretty fleshed out in a way, like it's on its way to being fully fleshed out.
Mm-hmm.
And then we're going back to Slack for other conversations because we haven't made that cutover yet. And I'm not sure if we will. Maybe we can talk about that here on this conversation. 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. Cause 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 and,
I think it could be cool to find ways to 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've had to pay for it. And it was 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-in and support from Zola. Yeah. In whatever ways. Like if we have ideas for how to make this even more community focused, then I think that there's... 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 community. channel about 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, you know, 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 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 how will they persevere?
I know the team is capable of doing it. Sure, but even if they don't, then it's an 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. 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.
Because I feel like that's my reservation 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, is the awareness. And something's got to change there. And that's where my uncertainty for them comes. It's like, you've got to figure out how to market. You can't be the best unknown tool in the marketplace. Right. 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 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.com. Opened back up again. Went full OSI-approved AGPL license. And Shay'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 Asay. Asay. Matt Asay. 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 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 Elastic. 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 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 RedMonk, did the analysis on a bunch of at least publicly traded rug pulls 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 and Zulip. I don't know. Email editors at changelog.com. It's probably the safest place right now, 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 a new in Zulip, where would it happen at? You know, that's the, that is the challenge not to go back there, but that's 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.
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. Yeah. 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 we just, it could be ephemeral. It doesn't have to be a long lasting thing. Just post your conversation in there and then, then Bob's your uncle.
Bobby's your uncle. Yeah.
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 is the challenge. 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, hey.
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, 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 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.
OK, cool. That's the front of the house. That's the UI layer that developers are getting. So what about the back end, the real limiting, the retries, etc.
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 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 changelog. That's U-S-E-P-A-R-A-G-O-N dot com slash changelog.
Well, let's talk about another change log 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 as 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, 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, just managing your own things. And yeah, the amount of learning is really not to be compared with. You can't fake it. It's just real. 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 breaks, right? And when you own it, you own the break, 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 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 learning, because 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, eh, 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. PyHole. Stupid stuff. PyHole 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. 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. Yeah.
For sure. You know, this person's, 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. Pilehole's in there. RouterOS, I won't read them all. Unify Controller's in there. TrueNAS 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. And you can pull the disk immediately if you need to and swap it and do some stuff with TrueNAS 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 how do you self-host VS 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. Right. And Coder.com does both, but what they do uniquely is when you, I ran, 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 why 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 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 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 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 environment. One more layer. This is something that I think is kind of cool is I have my Jekyll blog still yet. So adamstachowiak.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. Like it's all inside the Docker container, which I think is so cool and 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 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. Yeah. This is like a homesteading version of software, right?
100%.
Right? Yeah. Autonomy, man. Like, leave me alone. I'm going to 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.
Yeah. Right. I like Montana too. Yeah. 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, right?
Like 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 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. Cause like he mentions next cloud 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, I just seems like, Ooh, but maybe next time 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 you have an iCloud account. Yeah.
So you're, you are on this, you will own nothing and be happy, you know, world forum, world economic forum prediction several years back where it's like someone famously said and infamously, 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. Yeah.
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 debt if you.
What I mean by the reason why I say debt. You have to pay back. Is that 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. Like 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. Right.
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 you're 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. 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 will 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 navel-gazy 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.
Hmm.
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.
Jupiter 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 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. Yeah. Seriously. I didn't think what we've done. Really? Yeah. I didn't think what we've done is, you know, you don't know 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. 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 branded 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,
here 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?
Mm-hmm.
And, you know, doneness is the enemy of perfection, right? If you can't just get it out there, it's going to... 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 are answered to get momentum and move.
The reason why I'm telling you this story is that in the span of, you know, an hour, I... And solidified and created what has been in my mind 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, I was like, I kind of want to listen to the whole thing now. And it's just a fake. It's just, it's just episode zero teaser.
Yeah. There's nothing. There's nothing. Well, there's something in there. Well, but not, not yet.
I told you I would reveal too much. Sure. But it's, uh, 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, uh, 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, you know, 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. That's right. All right. Good. Solid flex. Stay tuned for 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. Yeah. 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. Yeah. Let Jared tell the true story here.
We're going to chapter that one, Adam flexes, and then we'll have 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 CDE, and you run on 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
And I'm also here with Todd Kaufman, CEO of Test Double, testdouble.com. You may know Test Double from our good friend, Justin Searles. So, Todd, on your homepage, I see an awesome quote from Eileen Nucatel. She says, quote, 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 like not holding their business back from delivering features, we felt was a pretty significant accomplishment. And it's great to, you know,
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 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 done without having a sizable impact on their team. A lot of the consultants on the project had some experience doing Rails upgrades, maybe not at that scale at that point.
But it was really exciting because we were able to kind of develop a process 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.
And very cool use of... I mean, 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 everything.
the actual video and audio recording and syncing, and then we export out of there into Adobe Audition for editing. We have a 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 stuff. 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 is a great, except for earlier when I said, here's a chapter.
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. We aren't doing anything. I think Riverside has, oh yeah, they have a mark clip button right there that we could use to 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 this. 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 WAV 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 WAV file. Can I interview you a little bit on this process? I feel like maybe they might get more mileage on an interview version versus a monologue version of it. Absolutely. So I know what we do. 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? Right. And so we upload the MP3 into our CMS, our website, our application. And then before that, though, we also sort of drag and drop this WAV file.
Can you talk about what you do to introspect that WAV file to pull out the chapters, to pull it into the CMS process? 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, right? 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 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 WAV 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.
Yeah, 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, just like the baseline data set. It's actually the conduit between Audition and Web.
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 were a fool.
We're not fools. The cool thing too is to 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 forties. 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 WAV 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 WAV file, which can take minutes, sometimes 15 minutes if you're on a non-Apple Silicon Mac. Yeah, too long. Like I've learned. Too long. 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, et cetera. So I just go into our admin, make the change. and we're good to go. So that's really cool.
All of the MP3 chaptering abilities, shout out to our friend Losh 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.
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 well 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 gonna notice or or less but someone's gonna 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 of, 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, when we marker taking the time in that post-production process to, 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. I may dedicate more. Who knows? But I, you know, doing that pass is like the final step. I would just say like chef's kiss moment, opportunity on a show. And maybe 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 going to bring out one from a recent show, but 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 too, 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? 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 go, 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 got to scroll, scroll, scroll to where you're trying to be at.
And so the experience of chapters has drastically changed in my opinion. 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 hanging out 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 three, Node adds TypeScript stripping for Nick.
Chapter four, Nick would absolutely love this. Chapter five, 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 seven 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 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 new stack About it. Because that's probably what Nick did in show notes was like, hey, this is what my reference point is. Right.
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 it.
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. I would just bail on it.
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 JSParty, GoTime, what have you, on YouTube now. 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 their 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. 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 100-ish per episode over there. But I think having chapters over there would be appreciated. So I'm thinking about doing that.
I haven't done it yet. Now we're basically Kaizen-ing, so maybe we should stop.
Sigh.
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 right. 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 you're 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. So, or a Slack for that potentially, where maybe you can hop in there into a dev channel. And if you've got some ideas, you know, obviously it's open source.
You can fork it and do what you want, but you know, you can contribute, you can leverage the code base to learn. Mm-hmm. Mm-hmm. 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.
uh 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 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 a thousand episodes in there.
Yeah.
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 PR away. There you go. But yeah, it's been fun to talk about self-hosting and 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? Oh, coming soon on the changelog, Jimmy Miller talking about the best, worst code base.
that should be good yeah yeah looking forward to that one so stay tuned right here and uh 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 is in there all all the stuff it's uh 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. 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 y'all in the next one. Bye friends.
Bye friends.
ChangeLog++ 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, Kuder.com, and Test Double.
And of course, to our longtime partners at Fly.io. To our Beatfreakin' residents, The 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 Change Log, news on Monday, Jimmy Miller tells us about his best, worst code base 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? Let me count the lines. Let me count the ways. 88,724 lines is the length of the LOCs on this file.
Yeah, 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.
It's better.