Reverse rug pull, so cool? (Friends)

30:43I 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.

31:27Both 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 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?

32:12Yeah. 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. 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 40s with a pretty large family, I don't have the patience or the time to self-host anymore, but I think everybody else should.

32:56Not 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.

33:35I'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 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.

34:07I would earn it over time, but I'm like... Battle scars. yeah i mean and you get better at it and it could become faster yeah because you're like oh i don't i probably 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 of 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 by all stupid stuff you You know, like. My whole sounds like it's critical though. It is, but it's so easy to run.

34:43Well, 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 like make sure that they're updated or fix them. You know, like getting it set up is the hard part. Right. They run while they run. Things go wrong here or there. You know, 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, you know, like that kind of stuff.

35:13But 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-hosting, and he gives a list of things that he is self-hosting. I'm trying to find a list quickly. At the top. My services, yes. Pilehole's in there. RouterOS. I won't read them all. Unify controller's in there. True NAS is in there. I think he even mentioned 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.

35:54It'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.

36:31I think it might be like this because coder.com is a cloud development environment so we've heard of this with like code spaces right and git pod 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 ran i actually have a coder.com instance in proxmox so i dedicated a brand new VM I created from Ubuntu, made that the CoderBox, 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.

37:15And 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 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.

37:52I 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. one more layer this is something i think is kind of cool is i have my jekyll blog still yet so adamstokowiak.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.

38:35That 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. This is like a homesteading version of software, right? 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.

39:15A hundred percent. 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. 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 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 And I feel like some of this stuff is probably him nerding out, which is totally fine to do.

40:45So 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.

41:35Even 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 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 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 iCloud if you have an iCloud account yeah so you are on this you will own nothing and be happy.

42:52You know, World Forum, World Economic Forum prediction several years back where it's like someone famously said and 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. 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 is that you commit to a payment oh you're renting 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 and I think renting is totally reasonable in certain cases.

43:50Like 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. 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 in history and reliability of that 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.

45:17And you should be in Zulip. 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.

45:52He says, you guys, if I recall, have some type of encoded timestamps to the MP3s. Destination Linux timestamp 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 super interesting to other people because I've been having some conversations with a future branded podcast we're producing.

46:31Oh, 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. 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. 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.

47:10I 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 flexor. 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 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.

47:44And 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 a version you know 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 right of 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 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 well perfection is the enemy of doneness that's 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 i'm telling 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 pretty that's a pretty good version of what it's going to be.

49:14It'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. There's something in there. Well, but not yet. If I told you, I would reveal too much. Sure. But it's, 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 you know had to go back and forth it was just done you're just inventing the future right in front of their eyes right your 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.

50:15We 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 answering my flex he's like Adam just be quiet 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

50:54what's up friends I'm here with Cal Carberry co-founder and CTO at Coder dot com. So Coder dot com is a cloud development environment, a CDE, and you run all the clouds, AWS, Azure, GCP, you run on-prem, and you're no stranger to competition, right? The competition out there is well known. But what shocks you, what surprises you about the state of cloud development environments and how developers are leveraging them? You know, it actually shocked me. The majority of our largest provisioned customers do not use containers with their development environments. They actually use VMs on like GCP, AWS, or some kind of mixture of them.

51:33One 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?

52:10It'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.

52:45It 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 Serles. So Todd, on your homepage, I see an awesome quote from Eileen, you could tell. She says, quote, hot take, just have Test Double build all your stuff, end quote.

53:30We 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 are 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.

54:11And 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.

54:50This 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 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.

55:32So 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.

56:15I 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. 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. where we own a separate account for each of our podcasts, and everybody logs into their own account.

57:00They 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, you know, 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.

57:42And their job is to basically cut out all the bad parts, which is just, you know, 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 is a 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.

58:14So 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 or you can drop a marker here 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.

58:52All of this is in just a 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 glossy and a bunch of stuff right? yes 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 very XML like Yeah.

59:47Yeah. 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.

1:00:29So 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.

1:01:15I'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.

1:01:54It 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 wave 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 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 WAV 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 date changes or title changes or slug changes, how those things permeate into the final CDN that actually goes out to the world?

1:02:50Right. 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 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.

1:04:11And 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 seven megabytes. You know, anywhere from 10 megabytes to 100 megabytes, sometimes bigger for Adam's epic interviews. But the WAV files are, 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.

1:04:55It'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.

1:05:34It 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.

1:06:13The 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. Like, 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. Nah. 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. Right. 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.

1:07:02And I'm in my 40s, as you've alluded to, you being in your 40s. 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 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 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 to mix down from the session into the wave 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 an 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.

1:08:39All 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.

1:09:16Our 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. because like there's a lot of listeners like i don't jump around the podcast so i have no need straight through and then they move on to their next episode and some other show yeah but i'm like that's fine 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 of put a lot into and uh i guess don't care so much that a lot of people get a lot out of it we'd love more people too 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.

1:10:42And 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 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.

1:11:22You 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, 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 steven and was 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 2 by the way 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 and so we 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 a own chapter dedicated you could just go just jump to that chapter right now and listen to it to me that's the cool stuff it's the 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.

1:12:58I 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.

1:13:39It 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 stuck on chapters. This chapter will never end. A recent JS Party episode is called A Nick Level Emergency. So Nick Neesey, whom you may know from JS Party and also from ChangeLog and Friends and other changelogy goodness, is a big TypeScript fan.

1:14:25And 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 it 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.

1:15:05Chapter 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. Right. 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?

1:15:57They talked about, you know, Nick level emergencies on this, 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.

1:16:40chapters 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.

1:17:21Like I would just bail on it. Like I'm just not going to like 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 changelogin. 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.

1:18:13We do not have them on YouTube. What I'm thinking about doing is creating a second feed for every one of our podcast propers 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.

1:18:54And 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 where 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.

1:19:29However, there's just not that many people listening on YouTube yet or maybe ever because we're non-video podcast. A good episode, I think most recent ChangeLog News outperformed and it was only a couple of 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 haven't done it yet now we're we're basically kaizen 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 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.

1:20:19Maybe 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, 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.

1:20:56With 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 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 a 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.

1:22:26Alright that's all we got for this week, thanks for hanging out with us coming soon to a friends near you Kaizen coming soon to a friends near you Natalie Pissinovich 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 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 it's a lot of hard work putting in those suckers and nobody reads them but computers.

1:23:14Yeah, chapter data is 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 it is. 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.

1:23:59ChangeLog++ 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.

1:24:40To our beat-freaking-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.

1:25:16So Jared, is there anything else we could talk about with this RSS feed? It's, it's a, 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 there.

1:25:48It's better.