Hey everyone and welcome to Developer Team. My name is Jonathan Cottrell and today I am finishing up my interview with Richard Schneeman. Richard works on a bunch of Heroku stuff. Specifically, he does Ruby at Heroku and he also helps run the Keep Ruby Weird conference. He created CodeTriage. He also created DocsDoctor.org. He's been working on some Ruby benchmarking tools. A lot of awesome stuff that Schneems is doing. So follow him on Twitter. S-C-H-N-E-E-M-S. That's Schneems. Make sure you tweet at him and let him know that you are enjoying this interview on Developer Team. You can also check out stuff that he's writing on his personal blog. It's Schneems on Open Source, Ruby, and Life. That's once again S-H-N-E-E-M-S.com. Now while you're listening to this episode, why not go ahead and open up the app or whatever thing that you listen to podcasts in and click or press subscribe. That way, whenever a new episode of Developer Team comes out, you will be able to get it without having to remember to go to DeveloperTeam.com. I love you guys going to the site, but ultimately, who has time to remember to type in things in URL bar anymore? So instead, do the lazy easy thing and just subscribe. It's easy. So here goes, the second part of the interview with Richard Schneeman. So it's interesting you mentioned Python. I was actually going to talk a little bit about Python as well because first of all, Python, for those of you who haven't experienced Python before, Python has documentation as kind of like a first class citizen almost in the language. It's really different from what if you've ever written a rake task, that's probably the closest thing to describe it by. But at the beginning of most Python methods, it's a triple quote string that explains what that method does. And obviously, some methods don't need that because they're simple enough that they're kind of self-documenting. But for things that are abstracted or whatever, it does basically what you would do writing documentation elsewhere. But then you can like generate that doc, you know, up the chain. But this has been in Python and kind of like a convention that the Python community has agreed upon for quite a long time. But I was going to mention it because I actually, when I first started programming, I came upon this really cool, this is like a long time ago, but it was delivered as a podcast. It was called Python Osmosis. And it actually reminds me a little bit of Docs Doctor because basically the idea was you just kind of sit back, you know, and you're like, oh, I'm going to do this. And then you're like, oh, I'm going to do this. And let somebody else tell you things, you know, like in the idea being like, okay, I need to learn Python, but I have no idea where to go. Like I don't have a path, you know, to start. And I have no programming experience at all. Maybe, you know, people listening to the show, you might not have any Rails experience. One interesting way to learn Rails is to literally just sign up on Docs Doctor and have it send you these documentation pieces, little chunks of documentation, because you'll learn like, you know, as you, as it's kind of like osmosis, you kind of let this stuff come into your inbox and read over it. And it becomes kind of like a, I don't know how to explain it. It's like if you read it every day, then you start picking up on things without even realizing that you're picking up on them. Yeah, absolutely. It's kind of like if you go, if you go somewhere that speak, where they speak a different language, and then one day you sit down at the cafe, and then you like order something, and then you're like, oh, I'm going to and you just realized that you just totally did that thing. Like without even, or, you know, in the case of the documentation, it's like, one day you'll get a piece of documentation, and you'll be like, oh, I already know about this class. Like I've already, I've already seen it, or you'll like be debugging a bug in Rails, and you'll be like, hey, yeah, this, this totally looks familiar. Yep. So I'm going to switch gears again, real quick. Still talking about documentation, but from kind of a slightly different perspective. angle here. How, if I'm writing documentation, for the first time, or like the fifth time, if I'm new to writing documentation, I need to know how, how do I write good documentation? You know, there's a lot of talk about how to write good code, you know, like, there's plenty of books about that. But getting involved in Docs Doctor, I think the biggest challenge there is, am I doing this the right way? Like, how do I make sure that I'm writing, you know, enough information, or that I'm not writing too much? Or, you know, that I'm writing in the style that is necessary? You know, what, what are the conventions, etc? So that's a really good question. There, there's a couple of things that I do. Most of the time, whenever I am writing documentation, it's because of, I thought the method worked one way, and it turns out it works a different way. And one of my favorite things for that scenario is actually putting an example in there that, that kind of hopefully shows to other people, if this is also a common case that you're trying to do, or something you're actively trying to use, then this is kind of, this is how you should expect it to work. So I love putting examples in documentation. And it, in Rails, actually, like the examples are probably my favorite part. I almost wish sometimes they would just like not, explain anything, and just like the only code examples of like, kind of the, you know, showing that method used, and like, how do you set up the class, and all these other things. But there's also plenty of other times when an example doesn't make any sense, or none of the other code in there makes, makes sense. Or none of, none of the other code in there is documented with, with examples. So I'll, I'll sit down, with Evernote, or, or TextMate, or something, and just kind of write out what I think it does. And, and like, if you just gave me a method that, that I have no idea what it does, like today, it's like, hey, go into this class, it's undocumented. And then I'll, after I've done that, just like based on the name of the method, I'll, I'll read through the, the line by line, and actually start describing, okay, like it, here's how it modifies the inputs. And, and then eventually, we'll, we'll say, okay, and here's what the output is. And once I have all of that written down in, you know, kind of a super rough draft form, then I'll take a look at how some of the other documentation is written. And hopefully it's in the same file. If not, sometimes I'll have to snoop around in Rails. Like, it's really common that what I'm trying to document isn't like anything else in the rest of the file. And so I'll find another function, or another method that is, that is sort of similar to it. And then I'll just try to rewrite what all of my rough drafts and my, my thoughts in terms of whatever style they were already using. And also, at the same time, if it, if it's like truly a style thing, like the, the best way to write, to document something is to document it. Like the best way to like start writing comments is to start writing comments. And yeah. Yeah. Yeah. When you submit a pull request, then, you know, I'm, I'm, I know it must have like, it's super painful whenever I get anything like closed or they're like, sorry, but no, thank you. But at the end of the day, like you learn something. And so like you mod, like, you know, you now know about this internal method and you know how it's used and how other things kind of fit together. And so it's not a total waste, but. Sure. Um, on, on the scenarios where they're like, where they are interested in that piece of documentation, then hopefully if you contribute it to a, um, a repository, then someone should say like, Hey, like, thanks. I, you know, I'm really happy that you're interested in this. Could we change the wording to do this? Could we maybe add a line break here? Could we, you know, double space this and, and they'll, they'll work with you hopefully. Um, you know, if not, if nobody, if you submit it and then no one, is like responds to it and nobody says anything, then you should tell, uh, tell everybody to get on code triage for that repo. There you go. Docs, doctor and code triage solve a lot of problems. Yeah. I mean, it's really, they do. Uh, it's funny though. I, that, that piece of documentation that I told you about actually ended up getting submitted. So, um, I, from my perspective, I think, uh, something that a lot of people don't, I guess what I'm trying to say is don't be afraid to have an opinion. Oh yeah, for sure. I think a lot of people look at, you know, like the rails project, you've been working on that for a long time and you're just now getting commit access, which sounds like, man, it must be like a huge hill to climb to be able to like, to contribute to something as important and, you know, well thought out as rails. But ultimately the people who made rails are making rails with opinions and you have opinions. Yeah. And your opinion matters. Like it doesn't matter how long you've been programming, like share your opinion. And it's very likely that something about your opinion will either help you to learn why your opinion needs to be shifted or it's going to be something that nobody else has thought of before. And like, guess what? Your, your, your commit actually just got accepted, you know, and it's in the, in the history books or whatever. Oh yeah. Yeah, absolutely. Like when I first started, I kept on thinking, like, Oh, somebody is going to just jump in there and they, they know this file, like the back of their hand. And they're going to like yell at me and make fun of me. And it's like, cancel your GitHub account. Yeah. They're going to find out where you live and shame you on Twitter, throw things at you. Um, like, you know, and it's no, it's like, we're very, you know, Rubius are one of the most happy group of programmers. Like, obviously there's, there's some, some bad eggs every now and then, but by and large, especially if you're, if you're on the rails project, every, we go, we really go out of our way to say, you know, thank you. Um, you know, if we're merging your pull request, we say, thank you. Like if I'm, if I'm closing your pull request, I say, thank you for submitting the pull request. Um, and, uh, yeah, you, you are probably more of an expert at that moment because you have an opinion and, and exactly. Like you said, um, it is, if you have real actual experience, that is, that's actually how, why rails is so good. And like, like basically 37 signals was like, Hey, we don't like how we're developing apps. We're going to make it how we think it should be made. And so like the same thing goes for documentation. It's like, you're like, Hey, I don't like how this is currently written. Here's, you know, here's what works for me. And, you know, maybe, maybe somebody's like that. Yeah, exactly. Like you said, it's, it's great. Perfect. Ship it. Or there's actually a really good reason it doesn't work that way. Right. Yeah. And a lot of people forget that, you know, rails was meant to be used by people like rails is not, it's not like a project for itself. It's not self feeding in any way. It's intended to be like used by you, you know? And so your opinion, if anybody's matters, your opinion matters, you know? Yeah. I think that's like, it's not like somebody's pet project. It's, it's meant to be used by everyday developers, you know, it's built to make projects with. Yeah, exactly. Cool. Well, so speaking of Ruby, it's no secret on this show that I'm a big fan of Ruby. I try to generalize some of the things that we talk about here. And I think these apply in a lot of different circles. I mean, yes, Ruby has a particular, particularly interesting community, but there, that doesn't mean that other language communities are not interesting. So just, that's kind of like a, let me back up and make sure everybody knows it. If you are developing in Python, you shouldn't be scared to share your opinion either. You know, I think actually you have a particular interesting relationship with Python, right? I'm sorry. You have an interesting relationship with Ruby who has an interesting relationship with Python. Yes. Yeah. So my, my wife's name is Ruby and she currently is coding in Python right now. Like at your house right now. Uh, yeah. Well, at, at, at her job. Um, but plenty, plenty of evenings she is like sitting on the couch. Oh, why is this deploy? You know, not working. I did, um, I did instill, like try to bring over the testing culture over into her Python app. And she, she has also written a lot of Ruby before this, her previous startup that she, um, she co-founded, was written in, in Ruby on Rails. That's cool. Yeah. That's awesome. So, uh, let's talk a little bit about conferences because, um, you happen to be, uh, kind of at the helm. You're, you're, you run, but tell me what your official, I don't know if you have an official title, what do you do for Keep Ruby Weird? What would you say you do here? You named it. There you go. You're the official name maker or whatever. Uh, yeah. So office space was actually filmed in Austin. I don't know if a lot of people know that, but that's what that line is from office space. Yeah. Some of the buildings actually still exist, but anyway, I digress. Uh, so, so Keep Ruby Weird is it's a conference we throw in Austin and it's about, uh, how great we think Ruby is and keeping it great, uh, by, you know, keeping it weird, uh, focusing on a lot of people focus on the business side of languages and the business side of programming. And like, sometimes you just got to go out there and play and that's, uh, and, and, and that, you know, that's how children learn and grow and develop and like adults aren't any different. So if we don't stop and do that, then we won't advance. Um, so, uh, Keep Ruby Weird started because we got a couple of guys together and some beer and then it just happened. And brats, right? I heard the story on, uh, what was it? Ruby, Ruby Road, knows, uh, uh, the thought bot podcast. You talked about it on. Yeah. Yeah. Um, I, I was sitting down with, uh, with, um, Caleb, Brit and Terrence it, uh, at Frank's and we were, yeah, we were having just some really good, they have homemade sausage of, of all different kinds. And, um, and Brit was like, Hey, we should throw a conference. And I was like, I have the perfect name for it. And, uh, and so together we've, we've all kind of banded together and, uh, and, and we threw the conference for our first year. It was incredibly successful. We sold out in like five hours. Uh, and we, we heard a lot of positive things from a lot of people who go to a bunch of conferences. So, um, can you hear that in the background? The, uh, the whistling sound that, uh, my Roomba just started. I'm going to go shut it off. Okay. Okay. Okay. Sorry about that. I'm back. No problem. Emergency Roomba turning off, turning off Roombas as a service. We, we, I got my wife a Roomba for Christmas actually. And, uh, it is, it is quite loud, but it's funny to watch her interact with it because most of the time she stares and watches it and like supervises it, you know, which is basically the same thing as doing it yourself. Totally. Well, so, so, um, I, we, I've had a Roomba for a number of years. We actually recently upgraded to a nicer one that has the programmable. You can like set it, tell it to go on. Um, and one, one of the things though, about being an adult and buying like adult furniture, like, and basically I'm buying things that like look, look really nice. And you're like, you're like, Oh, the house feels really homeless. They're like, you know, it feels like a home. Yeah. And then my Roomba sees it and it's like, LOL, I'm going to get stuck on that or under it or yeah, no, it just, it doesn't work at all. So like, yeah, we, I actually, and we, I'm actively thinking about getting rid of my like coffee table that I spent months finding like just the right one. Mm. Because we, I didn't consider it has a metal bar all the way around the base of it. So it's not, it's not that it can't clean under it. It'll get one wheel stuck. And then it's so annoying to pick up and move back to the dock that I'll just leave it there. It'll, it'll get stuck for a little bit. And then it'll be like, ah, can't go anywhere. I'm just going to turn myself off. The automatic scheduler will come back on in the next morning and it'll just like sit there. And it's like, it's like the, it's like the, the most, uh, it could be like a, you know, a short, yeah, yeah. It's like, it's like a little short film or something. It's just like, oh, poor, you poor little, you poor little thing. Sometimes, sometimes I just flip it over, but it has sensors in the wheels. So the wheels detect when it's like not touching anything and it doesn't run. It's like, okay, just lay, lay down, just calm, calm yourself. Take a break. Yeah. Um, go home Roomba. Yeah. Yeah. You're drunk. Um, so enough about, I think we were talking about, uh, keep Ruby weird. Yeah. Uh, uh, I was going to ask you a question about that. So the, the conference is about Ruby and it's about, uh, the community of Ruby, but also about a ton of other stuff. But I did want to ask you a kind of specific on the spot question. Tell me one thing about Ruby that you're not a fan of. Uh, I think it's about Ruby. I think it's about Ruby. I think it's about Ruby. I think it's about that is just patently weird to you. The one, the one patently weird thing about Ruby. Like that you would have never expected coming to, coming to the language. Um, I know I'm putting you on the spot a little bit there. So, so from a technical perspective, one of the, one of the, I guess, weird slash cool things, um, is like, is like, so I actually first learned how to do the first object oriented programming language I ever learned was Ruby. Um, and the first exposure I ever had to like the, or equals operator, which will basically say like, if this, if this value is set, do nothing otherwise set it, set it to this thing. Um, Ruby will Ruby supports that by like actually, um, doing a lot, like it doesn't have a special or equals operator. It actually evaluates both of them. Um, so I think that's, that's a really cool thing to do. Um, and I think that's a really cool thing to do. Um, and I think that's a really cool thing to do. Um, which makes it a nonatomic operation, uh, which actually has some problems with if you're doing concurrency code, but, but yeah, no, that's like a super boring, like response. No, not at all. Um, yeah. And I don't know why I like that. I just like that. And I think it is slightly weird that they like decided to do that. And it's like kind of a cool, it's like one of those cool continuity things where like everything, you know, it's, it's like everything in Ruby is a method. Um, well, and it happens to work that way. Yeah, exactly. It's, it, it's, or it's like, like, uh, it's like, like there, there's no functions. Like people are used to in like Python, you have, uh, it's like, like print is like a function and it's like in Ruby, it's like print is, it's like a method on some object up the chain. Yeah. I hope that's right. I think, yeah, I think it's on like kernel or something like that. Yeah. Yeah. I think you're right. Because I've, well, I've seen puts. It's on the kernel. I think we're, we better stop talking. But, uh, so my, but my, what I've been telling people, um, the reason I think Ruby is really weird is because it's the only programming language that's optimized that the official stated goal of Ruby is, is to be optimized for happiness. Like, that's what Matt, that's what Matt's the creator of Ruby. It actually says, it's like, what, what do you want Ruby to be like known for? And he's like, I want, I want. Ruby developers to be known as happy developers because they really enjoy using Ruby. Um, and like, there's a lot of, there's, there's a lot of thought and effort and energy put, put into that, you know, from, from the syntax to the way it's implemented to the ecosystem to, um, there, there's even a, there's even a saying in the Ruby community that says, uh, Matt's is nice. So we are nice. And, and basically like the, the community started as one. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Like you can't help but just like be – he's constantly smiling and it's just like he's super sharp. Basically whatever programming thing you want to talk to him about, like he has like an opinion on it or like he's been all around the world and done all these crazy things. He's still super involved in Ruby, super – with the core team. And the thing that gets me, it's like if you've talked to some career open source people, like a lot of them, it's just like they look like they just woke up. Yeah. Like from a bad, you know, like bender. Yeah. And they get tired of the projects they're working on a lot of the time too, which is sad. Yeah. And, you know, so like he's still sticking with it. And like obviously he is. He's still doing side projects and like, you know, hopefully – who doesn't? Everybody should have side projects. Sure. Of course. Of course. Yeah. You know, but it's just one of those things where like I – you know, I wouldn't say – I can probably program in like a handful of languages. Like I wouldn't say that I necessarily know them. But every time I like touch another programming language, I'm just like, oh, I just wish you were Ruby. It's funny, isn't it? It's funny how it works. Yeah. It just – it really – and maybe it's just because of the time and place when I picked it up. But it really just fits the way that my brain feels a programming language should work. Yeah. I think I agree. There's other – you know, I've worked in quite a few languages. As part of my degree, I worked in some Java. You know, I've done, you know, everything from Java. That all the way to, you know, just a few functional programming languages. But Ruby has consistently been, again, the most enjoyable, right? Like which – that's what it's designed to be is just an enjoyable language. And despite some of the – whatever the shortcomings are, that brings me back, you know? Yeah. Absolutely. Cool. That's – go ahead. I was going to say it's enjoyable unless you're trying. You're trying to write to a file because you have to use a block to do that. It's just like really? There's a file.read. Why can't we just like have a file.read? Anyway. Anyway. What can you do? Yeah. No. You got to pick your battles. Yeah. So speaking of things that you're doing other than Heroku and Ruby and all of those things that we've already talked about, are there any – are there anything – like any books? Or anything like that that you're reading or particularly interested or have enjoyed recently that you would share with me? So yeah. I've been reading through Pat Shaughnessy's book, Ruby Under a Microscope. It basically is all of the – it does a very good job of explaining – like so I don't have a computer science degree and it walks you through like what is a parser? And like here's how Ruby's parser works. And here's like – Yeah. And here's some examples you can use and then down through how actual individual features are implemented in the language. Oh, I totally should have said the singleton inheritance chain for the weird thing. But no. But it's – yeah. That's like way too geeky. But yeah. I've actually tried doing this like self-enrichment, like 30 minutes a day where instead of saying, okay. I'm just going to browse like blogs off and on whenever I get bored. Like if I'm noticing myself zone out, I work from home. So I don't always take full hour-long lunches. It's like basically for 30 minutes of my lunch, like I'll just sit down with a book and like with a timer and just like make myself learn something. I love that. So I've been doing that with Pat's book and it's good. It's like other than that, just some – Some reference books. I – like it's like Operating Systems I think is one of that I was reading. Nice. Which talks about like how memory management works. There's like many multiple chapters on it. There's like physical memory and virtual memory and it's like hundreds of pages to just memory. Originally, I was like memory is a number. It's like no. Like the amount of RAM you use. It's like – and basically nobody knows. Like the operating system, this like sophisticated of an operating system. Like it sort of has an idea of how much memory exactly you're using but like it would be – anyway, it was really, really interesting, really eye-opening and unfortunately, it was very applicable to something I was doing. That's funny. Yeah. Yeah. So – I've heard nightmares. I've heard nightmares. management. I also have a big stack of books on my desk. The art of computer, the art of computer programming, which I'm sure you've heard of and are at least cursory familiar with it. And a pretty good portion of that is pretty much just about memory. Okay. But more in the, in the classical sense of like, how do you write to bits? And, you know, what does that mean? And what what would happen if suddenly you had to do like a seven base system? Like, would you know how to do it? Oh, that's, which has nothing. And I don't know if that specifically is covered, but it's things like, like making you think that way. Yeah, that that is really cool, though. This was all just like, the, you know, how stuff works, I guess, of, of, of operating systems. That's cool. Other than that, oh, I subscribe to, to fine woodworking and rewriting. Reddit, Reddit's woodworking subreddit, I find both of them incredibly satisfying from a like, if you enjoy process, and you enjoy like step by step learning things, it's totally not programming. But I have not met a single programmer who has not at least been interested in geeking out on woodworking. I think the the working with your hands and like that kind of a craft, there's some sort of innate appeal there. I'm not exactly sure what it is. Yeah, yeah, I've actually wondered the same thing, because I recently, I recently got interested in and I haven't done anything with it yet. But Instructables, I downloaded the Instructables app. And I've just been like, you know, like, almost in the corner, like when I'm supposed to be doing something else, I'll open up Instructables and just like scroll down the list and see if I see anything cool that I might want to put on the list of things that I want to build. Yeah, totally, totally. I think it's the maker thing inside of us like we, we build a lot of software and, or whatever. You want to call it an app. And then like, it feels like we go home and like it doesn't it's sometimes it's hard to see that building under our like in front of our faces. And we can open up our phones or whatever. But like, for instance, I just got some beacons, some Bluetooth beacons. And I've spent some time just playing around with those. And I threw up a, like a Sinatra app. And then I think it was a it was actually I was inspired by a talk. I was talking about a talk that was given at RubyConf about Bluetooth beacons. But anyway, you can just kind of like, you know, if you don't know what a Bluetooth beacon is, basically, it's just a little. It's like a Bluetooth, it's battery powered, and it broadcasts a Bluetooth signal and your phone can listen out for that signal and then respond to it in some way. And so there's an app called beacon with two E's instead of an A. And you can send a post request whenever you hit that beacon. Well, I, I had it, I set it up at work today. And basically, I walk into a room and a song starts playing on the Sonos speakers, because there's actually a Ruby gem who knew that will take over the Sonos in the room. And it's, it's just like this really cool, like physical thing that completely captured my brain for a couple hours. That is that is really cool. Yeah, it's a lot of fun. What was that? What was the song? Oh, I just I think I picked like radioactive or something like similarly, you know, fill in fill in the adjective that you'd like to fill in there. I don't want to make a judgment on your musical taste. I didn't know if it was like I the tiger or like, I actually, okay, so I started out with something along those lines. I don't remember exactly what it was. It was like ACDC song or something. Yeah, yeah. I actually asked all the developers in the room. I was like, Hey, guys, what would be an epic walk in song? They had no, like no context for for why I was asking this question. So they started throwing out random stuff. I'm pretty sure I got like a Taylor Swift song in there. I was like, you don't understand what I'm asking. This is different than that. Nice, nice. Yeah, it kind of looks like one of the old jokes about like picking a song for like your, your, like what you wake up to. It's like, okay, you know, pick, pick the song that you're going to hate for the rest of your life. It's like, you got it. It's like very carefully. Right, right. Well, awesome. This has been enlightening. I've enjoyed it immensely. So one last question that I like to ask guests, and hopefully you'll, this won't be too much of a all of a sudden kind of question. But if you had to sit down with a brand new programmer or somebody who is relatively experienced in the field, and give them, you know, 30 seconds worth of advice, what would that 30 seconds be? Oh, that's really hard. Is it really bad if I just give them 30 seconds of silence? It's like the best code is the code that you don't write. No, I think my, my best advice for, for just anybody really is, and a lot of people forget this is, is, is like writers, right? Programmers program, like the best way to get better and get involved in this. In the community is just to do it. Go out there, figure, figure out, you know, make a goal and say, you know, like, Hey, at the end of this year, like, I'm going to get committed into rails. Like, that's not hard at all. Like, that's, that's, that's like, you're like lowballing yourself. And then, and then work backwards and say like, okay, what, what are the steps I can take to, to do that? And then just put yourself out there and take steps to, to, to doing it. And you know, it's amazing. And a year later, you'll be like, I'm going to do this. I'm going to look back and be like, wow, like, you know, hey, I'm a program, like, I'm a good programmer now. Or if you don't, then, you know, I'll tell you, you're a good programmer. That's great. That's good. Good advice. Just in keeping with actually quite a few, quite a few guests on the show have had similar responses. The best way to become a good programmer is to start programming more. Yeah, it's the secret sauce. Don't let anybody else know. Awesome. Well, thank you, Richard. I appreciate your time. Yeah, thank you very much for having me. This was great. And if there's, let me make sure we get all the links in here. DocsDoctor.org. Awesome. DocsDoctor.org. And then what was the other one? CodeTriage. I don't have my notes in front of me. CodeTriage.com. Yep, .com. .com. There we go. And then you've also got this other project that I want to drop in here because you had mentioned it before, and it's super interesting to me, the benchmarks one. Oh, it's, I'll send you, it's called derailed benchmarks. It's on github.com slash Schneem slash derailed benchmarks. Yeah, and the basics of that are, it's essentially you can spin up a Rails app without connecting it to a port and then interact with it. Yeah, and then interact with it in ways that will test it, like, from a benchmark perspective, not from, like, functional tests or, you know, controller tests or whatever, but from being able to say, you know, this code is faster than this code, right? Mm-hmm. Yeah, you can do that. One of the, I, one of the things I wanted to know was, like, hey, how much does, or, taking a step back, one of the problems we get a lot of times, at Heroku is people saying, like, hey, my, like, app is using all this memory all of a sudden, and one of the suggestions we give them is, hey, maybe take a look at your gems and see which ones that you aren't using, because in, everything inside of your gem file gets loaded into memory, and I was like, oh, well, hey, is there an easy way to see that? And so with, with this tool, you can run, if you, once you set it up, you can run rake, what is it, require bench, perf require bench, and it'll show you, every single time require gets called in your app, and how much memory that require consumed. So, so if you, like, if you require, and, and from this, we found that, that mail had a, was using something like 30 or, like, you're just requiring the mail gem was, was taking up, like, 30 or 40 megabytes. That's incredible. And then from that, we were like, oh, hey, we don't need to do this this way, we can do it this other way. And then we saved mail, like, anybody who's using the mail gem, you know, we cut off, like, 30, 30, 40 megabytes out of their startup memory time. And it's like, even if you're not using it, it's still loaded into memory, and it's still, like, you're still paying for it. So, yeah, it's just, it's just a bunch of different kind of stuff like that. Things that I, essentially a collection of things that I have found useful. Very cool. Very cool. Well, Richard, I appreciate your time, and thank you, for joining me on the show. Yeah, thank you. Thanks so much for listening to Developer Tea, and thank you to Richard Schnabes for being on the show. I know that this episode, this, this interview went longer than the average interview does on Developer Tea, but it was jam-packed full of value for me, and I think it was for you as well. If you're enjoying the show, make sure you let others know by going onto iTunes and leaving a review. It's the best way to help other developers find Developer Tea. You can always connect with me on Twitter at at Developer Tea. You can find Schneem's on Twitter as well. It'll be in the show notes, which you can find at developertea.com. There's also a contact form there if you want to ask questions or send feedback. And until next time, enjoy your tea.