Rooftop Ruby Podcast
Two Ruby programmers (Collin Donnell and Joel Drapper) discuss Ruby, web and native software development, technology, and more.
Rooftop Ruby Podcast
24: Travel, Developer Maxims, and Paid Gems
Travel, tech unions, developer maxims and paid Ruby gems.
Follow us on Mastodon:
Show art created by JD Davis.
Joel, big news.
Joel:Hey.
Collin:Hey, big news. We, I think we can talk about it now because we've nailed down like the time and they've said, but, uh, we're going to be at RubyConf. We're going to do a live podcast episode.
Joel:I feel like I'm waiting for an audience to be like, Yay!
Collin:Yay. I'll put in clapping there. Um,
Joel:here, so I'm gonna, I'm gonna celebrate with you. It's awesome.
Collin:Yeah, we're going to be right after lunch, I think on the second day, like 1. something like that. Which, I'm excited about because I think that's gotta be a great time slot.
Joel:Awesome.
Collin:I don't think either of us has any idea like what we're gonna do yet, but we have a couple of months to figure it out. So, I think we can come up with something good. I'm sure it'll be like different than a regular episode. Like, I don't know, special guests, maybe a giveaway. Uh, you know, all the things that, like, juice the numbers a little bit, get people to want to show up. Um, but anyways,
Joel:ideas,
Collin:yeah, if you have any ideas, get in touch, because we'd love to hear them. But, um, I may, uh, maybe I'll go back and listen to, like, other people who have done live episodes and try and figure out what worked and what didn't, because a lot of people have done this. Uh, but anyways, I don't know if there's a lot I'll say about that. We're probably gonna have more Ruby Central people on, because, we've been talking to them, so... That's cool. Um, Oh, I'm just going to mention it because we haven't nailed down. Next week, we have a really exciting guest, um, uh, Ethan Marcotte, is that how you pronounce his name?
Joel:I'm not sure. Oh,
Collin:I've never heard it said. So he's famous for being the person who coined the term responsive web design, I think. Right.
Joel:right.
Collin:And then he just wrote this book called You Deserve a Tech Union, which is exactly what it sounds like. So we both started reading it. We're gonna, you know, read it this week. And, um, I think that's gonna be a really exciting one. I just realized if we're both gonna read an entire book, that is by far the most we have ever prepared for one of these.
Joel:Yeah, I'm, I'm gonna try. I, it's I don't know if I'm going to get through the whole thing this week, but I'm going to try my best. I'm, I'm, I'm super excited to read this anyway. I've, I've been, uh, following Ethan for like, I don't know, even know how long since, since he wrote the book on responsive web design, which was, how many, how many years ago was that?
Collin:no idea.
Joel:Um, but this is, this is awesome. I'm really excited to, to see something else from
Collin:Yeah, it's really well written, so I think once you start it, um, once you start, like, getting into it further it really picks up and is, like, very well written, so I found it, like, very I'm not, like, we've discussed, I'm not, like, great at finishing books a lot of the time if it's not, like, If it doesn't have, like, a very compelling voice to it that pulls me in, and this really does, so. Um, so if you want to keep up, go get the book, and we, you know, we're going to be talking about it next week.
Joel:Yeah, I think this is a really important topic, and I can, I can tell, already tell from the first few pages that I'm gonna be, like, nodding the whole way through. Mm hmm.
Collin:yeah, yeah, I think it's great. But we're going to discuss it in super depth next week, so we don't have to get into anything about it now. Um, Also, uh, in what day is it? So it's Monday right now. So in about a week and a half, I'm going to be on a plane to Hawaii for, uh, Rails Camp West. So, uh, I went last year. It was in the, um, it was in Washington state in like the North Cascade. So it was like a pretty far drive for me still. It's probably like took me like six hours to get there because it was really in North, I'm in Oregon, but it was still like in like North, Northeastern, uh, Washington. You know, pretty far out there, um, but it was, I'll send you some pictures of it, maybe I'll link them, but it, it was incredibly beautiful and it's not a large group, so it's a camp, there's no talks, there's no, it's not like a conference, they have like things you can do, like this year they have learning surfing, last year they had like how to identify trees, and how to row a boat, like stuff like that, or like take you on a boat ride anyway, and you row it, um, I don't know how much there is to like the technicality of rowing a boat, I didn't do that part, but, um, They have karaoke. It's great.
Joel:I'm super jealous. I wish I was going to this thing.
Collin:I would, I would, it'd be amazing if you go next year. Um, it's also cool because it's not like that expensive. I
Joel:Uh huh.
Collin:It, it is, but like, it's like, it's less than going to RubyConf. It's like 700 or so, and it's all inclusive. You stay in a cabin and the food's all included and everything. So like, I really, I don't think it's like the person who puts it on. I don't think she's not like. She's not, like, trying to do this to, like, make a lot of money, I don't think. I think she's trying to do it because she likes doing it. And so she really, like, has, you know, tries to keep the price down. So it's really, um, and they have some, like, scholarship tickets, too. So I think it's, like, fairly accessible as these kind of things go. Um, and also it's not, yeah, it's also, it's not huge. It's, like, 30, 40 people, but maybe a little bigger. It's in that range. Um, but it's everybody you would want to meet a lot of the time. You know what I mean? Like, it's a lot of. Very cool people who you'll find out like you'll talk to them and somebody will be like, oh, yeah I was the maintainer for like I was the primary maintainer for like Ruby 1. 8. 6 or something and like Really, you know cool people like that It's like been around a long time and so you learn a lot actually just like talking to people
Joel:It's kind of like the conference, the hallway track, um, at a conference, but all the time. And also, like, in the outdoors.
Collin:yes,
Joel:sounds amazing.
Collin:Yeah, cuz for me like actually the hallway track is I mean besides going to our podcast episode the hallway which everybody should do The hallway track is like the main thing. I actually really like about conferences Um, I just like chatting with people and making new friends and getting to explore a new place But yeah, it's in Hawaii. So it's on the north coast this year and then I'm going to be staying in Waikiki for a couple of days after, which is kind of famously beautiful. I'm going to get an Airbnb. I need to do that. But, uh, so yeah, I think it's going to be great. I'll let you know what it was like, but I'm sure it'll be a lot of fun. Um, I did feel a little bit, this isn't a criticism because obviously Hawaii is amazing, uh, as a place to do something like this, but I did feel a little bit like Hawaii is really, is really stretching the term Rails Camp West. Cause it's more like Rails Camp Pacific this year. Um, but I'm still really excited. I don't know if I mentioned it. I think it's, it's the first time I think I've been on a plane since like 2019. So like before COVID, so I'm a little bit nervous,
Joel:Oh wow.
Collin:yeah. Have you been on a plane recently?
Joel:Yeah, uh, I actually did a lot of travel towards the end of COVID, but when there was still, like, really stringent, uh, I Like, requirements for traveling, so you had to get, like, tests, and they had to be... You had to have, like, a COVID test that was taken within 24 hours of your flight departing, and that kind of thing. But there'd be, like, very few places where you could get these done, and sometimes you wouldn't have your results on time, because they take, like, 24 hours to get to get turned around. Um, so that was an incredibly stressful time of traveling, but yeah, I've been... Mainly, like, going out to France and Italy for skiing trips and things like that, but...
Collin:Man, living in Europe sounds so cool.
Joel:Yeah, it's pretty awesome.
Collin:Yeah, it
Joel:I mean, I think living in the States sounds pretty cool as well. Like, you can just drive anywhere
Collin:You can drive from Portland, Oregon to Atlanta, Georgia.
Joel:Yeah, like you did the other day.
Collin:yeah, I'm, I'm, I'm definitely not doing that to go to San Diego. It seemed like it would be number one. There's a thing I had to get back to the next day. I'm going to a live podcast recording actually, but, um, I'm definitely not doing that to go there and I wasn't going to anyway, because I found out. Like, it seems like it'd be closer because it's on the west coast, but actually driving from here to there is like driving from here to Nebraska. Like, it's really far.
Joel:Yeah,
Collin:really, the United States is so big. Um, but yeah, so that'll all be exciting. I'll let you know. Um, oh, I had a good, I had a good toot, uh, that, that, uh, I think you saw. Which, I'm gonna try and remember it, but it was, I've gotten pretty okay at JavaScript. And having gained that more like nuanced perspective, my initial, my initial feeling that scoping in JavaScript is entirely batshit was definitely correct.
Joel:hmm.
Collin:I don't, I don't know if you have anything to say about that, but I, I just wanted to share it that I've gotten better at JavaScript. I've like put some work in and I still think it's insane.
Joel:I'm not sure if I even understand scoping in JavaScript, to be honest with you. Mm hmm.
Collin:Well, anything that's, so somebody will correct me. Cause like. I'm not that good at this, but, and other people are very good at JavaScript, but, uh, and I'm sure many of our listeners are, but, so anything you give an ID to on the page, right, is like globally scoped, and you can get to that using like, what is it, like query for ID, whatever that function's called, and that's like the preferred way to do it. You can also get at any of those just by like naming it. And so that applies inside of your classes too. So like. You can make JavaScript class and stuff, but still anything like that, it's just accessible to, they're just global, which I think is crazy. And then there's also the thing about like, For example, if you create, I'm trying to think, like a timer, and you want it to be called back, the sort of context in which that is called back means that the value, which is this, is different than what this was when you called it. Like, it's like the window now or something. Unless you call another function to bind it to the object that you are calling it from. It's very weird.
Joel:Okay.
Collin:Um. It's very weird, so like stimulus actually makes a lot of sense as like it's pretty lightweight, but I'm like, oh, yeah That's why they have all of the like, you know data data target, whatever equals, you know something Because otherwise you the scoping is just nuts. So you can't really get like good encapsulation Otherwise, somebody can correct me if I'm wrong I feel like every time you talk shit about JavaScript somebody's gonna be like, you know Actually, ES6 is really good. And I'm like, no, it's not that's what I've been using.
Joel:Yeah. I c I've, I really miss the days of, of CoffeeScript, personally. I think CoffeeScript was amazing. It was so simple, it did everything you needed it to do, and... The code was so easily readable, and processable, and understandable. And, it didn't do anything else. And that was great. Like, it's, it had such a small surface area to understand. I loved CoffeeScript. I think it was great.
Collin:Yeah, but then, I mean, the thing about languages that compile into other languages, maybe other, apparent, as far as I can tell, no one else cares about this, except for me, because everybody else uses TypeScript. Uh, not everybody, but like a lot of people, um, but like. It does feel like there's a trade off that doesn't get acknowledged of having a language that compiles into another language. Like it's making your build system more complicated. It's doing other things. Um, maybe it makes, you know, debugging from the browser harder, things like that. Um, and that just feels like a trade off nobody talks about, but that does feel like a trade off to me, which I think is,
Joel:I can, I can definitely see that. Especially with regards to debugging. I mean, All, all the languages that we work with compile to other languages eventually. Like, they're compiling to machine code, and like, at least from the outside, it, to me it makes no difference if it's compiling to an intermediary language first. Uh, unless, unless your debugging experience becomes, like, exceptionally bad.
Collin:Yeah, I know that the, I think it's Svelte or, I'm like, I'm not up on all these fancy JavaScript frameworks, but I think it was Svelte or SvelteKit. They went from TypeScript to basically just using like their equivalent of YardDoc, which is like JSDoc, I think, uh, because they're like, we can get a lot of type checking with this and then things like you're not, you don't have to compile libraries, I think was the deal. So you can just step into a library and then see the code and it's like more easy. For debugging and like understanding things, but people can look that up. I'm probably misquoting it because I'm not like a JavaScript developer. Thank God. Um, okay. So I pitched this idea to you and I, I will read this post, but, um, it was basically this guy talking about, uh, performance and the idea of you. What is it? It's premature Optimization is the root of all evil is the quote, right? And basically I'm just gonna read the whole thing So it's not very long. This was linked by MJ Tsai, which is a blog I follow and I'll just read the parts He quoted but this was by Milyn Dezumerov I may be mispronouncing that probably but Okay, it has been commonly interpreted as don't think about performance in the beginning. You can fix any performance problem later. This interpretation is completely and categorically wrong. With the additional context, the quote takes on a significantly different meaning. It's making a statement only about micro optimizations, small efficiencies, not about performance in general. Hoare was simply advising against micro optimizations without finding... The hotspots first. The premature part refers to lacking measurements. As techstack fundamentals, access patterns, data dependencies, and data structures are baked into a design, it's not possible to hotspot your way out of a slow architecture. What do you think?
Joel:Uh, I love this post. I think this is, um, This is just, I completely agree with everything, everything he says. Um, yeah, I, I have heard that whole, like, premature optimization is the root of all evil, quote, used in the wrong context too many times to count. And, um, I think what's key here, in the, the last paragraph really sums it up, is, like, Yes, you can, like, you can do these, like, small tweaks and things like that to get some extra performance. And maybe doing those early isn't worth it, especially when you're not measuring. But the thing that you absolutely can't just, like, tweak later easily is the fundamental, like, architecture of your system. If you've architected your system with, like, bad design that didn't consider performance early on, then there's no small tweak that you can do to make it fast. Like, it's never going to be as fast as it could be had you architected it correctly. And I think that's, like, really key. And, yeah, completely think that we should all be... Keeping performance in mind, like, at every step, not just, like, well, I'm, I'm building it now and I'll think about performance later because, you know, it's premature to do it now. It's not premature to think about it now. If you haven't started, now's the perfect time to consider, like, what is the, the best, like, layout and access pattern and, like, data structure that I can use for this feature, for this system that's gonna make it fast, like, for whatever we're trying to get from it. Yeah. completely completely agree.
Collin:Yeah, and I, I have a sort of concrete example, which is when I was working on the, uh, Reminders app. There were some decisions made about, like, it has a daemon and it has an app, and they had to communicate. And basically, like, I don't know how I, you know, so many months into developing this thing we were gonna, like, redo that, right? It was kinda baked in. But then we found out, like, oh, if you get so many thousands of reminders, which you get because it was keeping on old reminders, just kind of archive them,
Joel:Mm hmm. Mm
Collin:um, like the app sort of stops working, right? And at that point, like, we weren't going to hotspot our way out of that. We needed to release this thing in a few months.
Joel:Mm hmm.
Collin:And that's, that's what I think of. Another sort of thing I think of is, like, yeah, the sort of micro optimization for me would be When you're developing it, maybe use a regex, and then you find out like, Oh, using like a string, like a scanner would have been a little faster. Like, that's an easy, like you see, you're like, Okay, regex is way more convenient, and if this is a problem, it's easy to change. Like, I can change it, it'll be more complicated, but if it's worth it, we'll find out. Like, we can measure it later. Where, in the beginning, maybe that wouldn't be worth thinking about.
Joel:Yeah, yeah, especially if you have to go out of your way to, like, do some, like... So, like, sometimes you can be in a situation where you think, if I was to write these five lines of code, it's going to be slightly faster than this one line. And that's probably the kind of thing where, that you're doing a micro optimization, and if you haven't actually measured and shown that that one line is consequential, then probably you don't need to worry about that. Um, but I think that it's, it's important to not Like, apply this rule too early and like, to the point where you're not paying very careful consideration to your basic data structures and things like that. Uh, and, and particularly like how you architect a database, like that stuff is really important. Thinking about what are going to be my access patterns through this database. So, like, where is the data going to be stored? How are the what tables are we going to have? How are they going to associate with each other? What indexes are we going to need? You know, thinking through all the queries that you're going to be making, and how many steps you're going to have to make to build whatever result you need from that. Like, that stuff needs to happen as early as you can. Uh, because, like, ripping that stuff apart and changing it later on is quite difficult. Um, Like an example at work at the moment, um, I'm working on, uh, let me think how, how best to describe this. So I'm working on basically improving the performance of, uh, kind of like sets of. Sidekick jobs that we run, um, so they kind of like run in these, uh, like steps where each step will trigger maybe like a hundred different sidekick jobs. And then we move on to another step, which then maybe runs one or two, and then another step runs a hundred. Um, and in between these steps, we're like saving to this special Redis database. It's not a database, whatever you call it, Redis store, uh, and like this, this architecture, it's just not going to work, um, in terms of like scaling it. We can probably scale it maybe two, three, four times what it is now. There's no way we're ever going to scale it like a hundred times what it is now. Um, and so. We're kind of, like, going back and having to go right back to re architect it from scratch. Um, which is to say, like, we're taking all of these steps, uh, and we're kind of, like, we have like a hundred different psychic jobs independently writing to this one Redis cache so that one job can pick up all of that information. And the reason that we're doing it is because we have to make a hundred different HTTP requests. So what if instead we had one job make a hundred concurrent HTTP requests and just keep them in memory, right? And then let the next step use this, use the active memory. Uh, and not have to go through any of that process, any of the, the psychic queuing and, and like, reading from the queue and everything that it, that it has to do. Like, this is, this is just an example of where I think, um, this, like, this is what happens if you don't do that very early, like, thinking about your access patterns and your data structures. And, you know, no micro optimization was going to change this architecture and make it 10 times faster, which is kind of what we need to do. Does
Collin:Yeah, like you Yeah, like you can get percents out of this. You can make it a little better.
Joel:Right, yeah. Yeah, you're never going to get like a 10x performance improvement from, from the same architecture.
Collin:Yeah. And I mean, it's difficult. Because, you know. Um. Much like with reminders. With that whole thing. It probably wasn't apparent, you know, like they were all really smart people. You can't always see it in the beginning, so you're still going to end up in that situation. Like there's, it's a difficult, um, but yeah, I think you can.
Joel:But you can, you can always do the best effort that you can do right now with the information you have. And I think that's, that's where I would say don't, don't use this to like, stop someone from making best effort performance design right now with the information they have.
Collin:Yes. Yeah. What it reminded me of, and part of the reason I wanted to send it to you was, you know, you mentioning like getting in trouble, uh, at Shopify for not like. duplicating something enough times before you create an abstraction or whatever,
Joel:Yep.
Collin:you know, because, like, duplication is better than the wrong abstraction, and they both just seem to me like things that are, like, it's very, it's very attractive to create rules, because then you can apply them, and you don't have to think about them. However, Like, neither of those things to me is something you can really turn into a rule because they're, they're like, way too vague. Vague. They're way too vague.
Joel:They're really, they're really nuanced.
Collin:yeah, they're more like guidelines. It's like
Joel:yeah.
Collin:about.
Joel:And our brains, like, are searching for these little one liner maxims that we can carry with us and apply to every situation. And it's just, it just doesn't work.
Collin:Yeah, like, I think I mentioned to you, like, an example of something that I could turn into a thing I'm going to do is to say something like, gotcha. Whow, whow, whow. We're only going to use accessors to, we're not going to use direct access of instance variables or, you know, unless we need to, um, for like specific reason, like that's something that is a little more clear cut, even though there's going to be exceptions to it. If you decided for a reason that was the way you were going to go, um, but like saying premature optimization, whatever, like that's not a rule. That's a thing to keep in mind. That's like a thing to think about. Yeah.
Joel:Right. Yeah.
Collin:So I don't know, I feel like we just both agree with that, but um, I don't know, I'll link to the post, I think it's really, uh, yeah, I think it's a really good thing to keep in mind that I probably, earlier on, did not, would not have, like, been able to understand the nuance well enough to, to have made that distinction, you
Joel:Mm hmm.
Collin:maybe only in the last, like, few years, I would have,
Joel:hmm.
Collin:I would have gotten that.
Joel:Yeah. What, what annoys me about this is I feel like these kinds of things are things that you say and a junior programmer's gonna pick them up and be like, okay, so I need to not think about performance until the end. Mm hmm. Mm hmm. Until, like, something's going wrong, and there's a problem to fix, and then I can measure, and like, then I can, like, think about performance. Because that's kind of like the, the, that's like what people, I think that's the interpretation that a lot of people bring from this. And it's just not great. Like, it is a good practice as an engineer to constantly think about the performance of the code you're writing. And, yeah, what's going on when, when you, when your code executes, like you don't necessarily need to do something about it, but you always need to be thinking about it. Like, that's, I mean, I, I say always need to, I'm again, at risk of like throwing up these big rules, like, you don't always need to be thinking about it, but it's a good idea to think about it quite often, right?
Collin:You need to have a sense for it,
Joel:Yeah. Yeah. And you need to, you need to develop a sense for it, right? You don't need to have a sense for it, but you need to develop a sense over time. If you're a junior programmer and you're, you're learning to code. Thinking about performance is not a bad thing. Thinking about performance is a good thing. If you're interested in performance, explore it. Like, dig into it.
Collin:Yeah, it's really important But yeah, I think that that I don't know I think just the takeaway of you can't hotspot your way out of a bad architecture is Absolutely true. I mean no matter what you do, like I said, I think you're still gonna end up with times where it was unavoidable because you just couldn't see everything up front, but I still think like having, having a sense for it, having it in mind is probably going to still allow you to be in that situation a lot less often.
Joel:Yeah. Yeah. So, the fact is, whether it's about performance or about, like, just being able to make something work with a new feature or a new change in requirements, You are always going to end up in a situation with bad architecture, and that's where you get to do the really fun work of knowing that you have bad architecture, and maybe figuring out the architecture that you wish you had, and then making a plan for how you're going to move from the bad architecture to the new architecture in as many steps as necessary. As few steps as possible, I guess, and, like, without breaking anything in the meantime. And while somehow managing to keep everything in your head and, like, not lose what's going on and also communicate that with everyone who's working on it and, like, not break things for people who are working on it, uh, and that's, that's actually the majority of what we end up doing, I think, as engineers, is basically, like, changing something from being an One way to being another way through a slow process of iteration.
Collin:Absolutely. Um, you know, and I think these, this kind of thing in particular I think is the sort of thing that Can take years to learn like some people are going to learn it faster than other people. I'm probably slow, but um You know I think this is the kind of thing that like as you progress like you're going to start to see it more and That's okay. Like it takes time
Joel:yeah.
Collin:Yeah Do you want to talk about paid gems?
Joel:Yeah, yeah. Um, yeah, so I am, have been thinking about launching a new gem. Uh, and this time probably it's going to be a premium extension for Flex. Uh, and... There aren't many paid gems out there, so there's Psykik is the only one I can think of, probably a handful of others. And Psykik has like this kind of freemium mode where they have a free version, and then there's a pro version, and then there's a Psykik Enterprise. Anyway, but I was thinking, what is the right way to distribute a gem? That is like not an open source free gem, but it's a paid like premium product
Collin:hmm
Joel:Like, is it cool to distribute it on RubyGems and have a license key built into the gem? Is that, like, not cool? Is that against their terms of service? Or, like, at least against the spirit of RubyGems? Um, like, if not, like, maybe is the right way to go to, like, have your own gem server? I'm not sure. Um, yeah, I don't know if you have any thoughts on this.
Collin:even... Yeah, we were talking a little bit about the idea of, like, having, like, a license code sort of thing, um, versus, like, if you have your own gem server, you can have something where, like, you have to authenticate with it, like, maybe. So, it... It also seems difficult because, ultimately, with Ruby, like, you are going to be... Like, they are going to have the source for it. So it feels like a license key for a thing that's on RubyGems feels like it would be, if people wanted to pirate it, would be, like, particularly ineffective.
Joel:I think if people want to pirate it, they're gonna be able to pirate it. You know, if there's a license key required, there's probably going to be one line of code that says, like, raise an error if there isn't a license key. And then you could just delete that one line of code, and then you can distribute it, say it, post it on RubyGems, say you made it yourself.
Collin:Yeah. Mm
Joel:All that stuff, but um, I'm not so worried about that. I think that's probably not, not gonna be an issue, at least in terms of, I don't think it's gonna really hurt my sales, if that makes sense. Uh, not that I'm sure if I will ever get any sales anyway, because selling gems seems to be like, something that people just don't do.
Collin:It's hard to
Joel:but, but, we'll see.
Collin:Yeah.
Joel:so it's hard to sell anything to developers, I think.
Collin:Especially something they're not used to paying for. It is always strange where like, if you, okay. So if you don't like using an ID like RubyMine or whatever, like I've been on different apps actually, but like, if you don't like that kind of thing, it like doesn't speak to you. That's one thing. The thing I always think is funny is where people are like, I tried it. It was amazing. I don't want to pay for it. I'm like, it's like 10 a month or something. Like, this is your job. That's crazy to me. Um, if it's like pretty affordable, you just don't want to pay for it. Um, like, you're a professional software developer. That's crazy. If it's actually going to make you better at your job. Um, yeah. I think it's hard to get people to pay for anything, especially something they're not used to paying for. Um, the licensing thing makes me think about, like, I know a lot of people who've made Native Mac apps and had to do some kind of a licensing thing, and in that case, the people who get it don't have the source code. Um, and yet, uh, what I've always heard is basically if somebody wants to pirate your app, like they will find a way and. If you like playing the game of trying to make it harder for them, like if that's entertaining to you, like a chess match or something, uh, Then, uh, you can do that, but ultimately, like, they will find a way, like, there is going to be a way to pirate your thing. And so, putting too, too much effort into that is probably kind of not that helpful. Um, yeah, it seems like, yeah, Sidekick sort of has the premium extension model, and then I was thinking, it's not a Ruby thing, but I was thinking like Tailwind UI, where like Tailwind is free, but then you can buy, like, all there. Components and stuff, which seems also like something that would be incredibly easy to pirate. Because I think TailwindUI boils down to like, they're going to give you the strings or whatever to like, make the components a lot of it. Um, which seems also incredibly easy to pirate. So, people still buy it though. So maybe if you, if you provide the value, people
Joel:I'm not, I'm not worried about piracy at all. I'm more thinking about, like, what's the practical way to do this? Like, maybe I can sell it on, like, um, what is it, Gumroad? That website that people sell things on,
Collin:Oh, I, I've only ever sent for books. I didn't even know they did other things.
Joel:I think you can sell software on there, um, but then, like, so that, that part's probably pretty easy, uh, but then how do you distribute it? I think maybe, like, maybe if it's easy enough to set up, having your own gem server is probably the way to go. So you'd say, like, you'd specify in your gem file. This is my gem. This is my, uh, And, and like use this specific source, you know, that's not RubyGems. org, but it's something else. And maybe you just have like the key in that URL. I don't, I don't even know, but, uh, I, I think that might be the better way to do it because then at least if, you know, if, if you're going to have a workaround, your workaround won't allow you to get updates.
Collin:yeah,
Joel:Whereas, like, otherwise, if you have a workaround, you can just keep pulling down the gem and you've never bought a license key, uh, but you can, like, just unlock the gem by, by, by, like, removing one line of code or, like, monkey patching it. Um.
Collin:absolutely, I think that is, yeah, I think that's correct. I think, after you said it, I'm like, yeah, that seems like the way to do it. This has nothing to do with Gumroad, right? But do you remember what Silk Road was? The thing where you could, like, buy I didn't do this. The thing where you could, like, buy drugs on the dark web, like, I don't know, 10 years ago or whatever. And the guy ended up, uh, going to jail for, like, life. Uh,
Joel:Oh, wow.
Collin:know, forever. And, um, and the funny thing is, when I lived in San Francisco, uh, this guy lived, like, one street over from me. And, uh... Yeah, and he's like this big criminal who, uh, who is in jail forever now. Um, I thought that was pretty wild. Um, Well, anyway, I think there's a really good episode. Uh, I don't know if there's anything else to say about any of this right now, but, um, Yeah, so, uh, as always if you like the show, I mean, number one, thank you for listening. I don't know if I always remember to say that, but like, thank you for listening. It means a lot to both of us. And, You know, please tell your friends, tell your friends friends, tell everybody. Uh, and also, like, uh, I really, I really hope we meet some listeners at RubyConf. I met a few people at RailsConf, but, uh, you know, this time we're going to actually be on stage, which is insane. Uh, and I think I, for one, I'm like super excited to see who comes.
Joel:Yeah, me too. Can't wait.
Collin:Yeah. So with all that said, uh, we will see you next week.
