Rooftop Ruby Podcast

11: Still Nowhere Near Portland

May 02, 2023 Collin Donnell Episode 11
Rooftop Ruby Podcast
11: Still Nowhere Near Portland
Show Notes Transcript

Follow us on Mastodon:

Show art created by JD Davis.

Collin:

So this is only marginally Ruby related. Really not Ruby related at all. But it's actually the main thing I've been thinking about this week, um, in regards to you since you're my European friend, which is that I learned that, and you're gonna have to correct me if I'm wrong, that in Europe or in the uk, the only water which is considered potable like you can drink, it comes from the kitchen. And that is because the water pressure is not enough there to, I guess, drive the water to the other parts of, to all the parts of the house at the same time, something like this. And what is done is the water is then collected in a large tank in the attic, and then that water. The, the, the water, which like could have anything happening to it seemingly, uh, in the attic is then used for bathing, brushing your teeth, all of these things. Am I correct? Am I understanding this correctly?

Joel:

That sounds like a reasonable thing to do if you have really low, low pressure water, but that's not correct in terms of like, that's not typical In the UK typically plenty of pressure to get water upstairs.

Collin:

Okay, so all the water is potable, like where you live and in a lot of places. So this is more of an older thing

Joel:

e I've lived in the uk, there's been enough water pressure for that.

Collin:

Okay, good. All right. I was very concerned because I'm like, you know, I imagine there's this open top tank, cuz you can look this up. If you look up European water cistern attic, there's just these open top tanks. It looks like, uh, I heard about this on the Reconcilable Differences podcast, uh, last week or the week before. Uh, there's these open top tanks. Looks like just anything could fall into them. And apparently this is what people were doing for. Many years, uh, and I'm, I'm glad to hear that you are not using, uh, the water that like errant rats can crawl into to brush your teeth, cuz I would find that very concerning.

Joel:

I mean, you could cover it, but you still wouldn't want to drink from it.

Collin:

No, I, I don't think I'd want to use it for anything. I, I think the whole, the whole concept of like, this water isn't potable, you can't drink it, but I can put it in my mouth for other things like that seems like a very, a very strange system to me. Um, but I'm glad it's not one that you currently live under.

Joel:

How, how was this Ruby related? You mentioned it was somewhat ruby related.

Collin:

No, it's not Ruby related at all. I've just been thinking about this nonstop for a week, and I was like, I have to save this for the podcast. I have to ask Joel about it. Um, but um, but anyway. How, how, how has your week been?

Joel:

Yeah, it's been good. I've been kind of following along with the whatever people have been posting about RailsConf and wishing I was there. Um, also just doing my work. Um, I've done a bit of extra work on green dots lately, is,

Collin:

Mm-hmm.

Joel:

My kinda experimental testing library. Um, so that's a bit fun.

Collin:

Yeah. What did, what did you do with that?

Joel:

Yeah. So, uh, basically I'm working on adding support for custom matches.

Collin:

Mm-hmm.

Joel:

kind of similar to, uh, matches in our spec, but I wanted to make them a little bit simpler. Um, so from the, from the perspective of like the person who's building the matcher, uh, instead of building. A matcher using like a special DSL that you have to learn. You can just define a module and you can just define the matcher method on that module. So it might be, um, let's say you're building a matcher for html, uh, and you wanted to match a CSS selector. You could just define like an H two one matcher module, and then you could define, don't know, uh, has selector or has tag. And use n um, like figure out whether or not that's true.

Collin:

Oh, that's pretty cool. That seems, that seems pretty useful.

Joel:

Yeah. So, um, I wanted to make it so that it was just as, as simple as defining a module and a method and then you could reference, obviously that method could take arguments. So like has tag. And then a symbol as, as the, the name of the type you want to search for, and then you can just compare that against the value. So, um, when you make an expectation, uh, you end up in this expectation class that has this module included and it has available to you, uh, the method value, uh, and also the method block. So depending on whether you want to. You can build a matcher for a block you can build a matcher for like a, a value. And, and blocks are useful for, for example, um, if you want to do a matcher, like, um, that this block raises something or expect that this block doesn't raise something, uh, it can be useful to Basically delay the execution of the block until after your matcher has done something and then it can like call the block, if that makes sense.

Collin:

Yeah, that makes sense.

Joel:

so yeah, there's a couple of ways you can do that, but the, the main thing that I wanted to do was, uh, figure out a way to get, like, to make it so that you could define matches for specific types of object. So, um, if you can imagine. This, I, I mentioned this like has tag matcher for html, uh, documents. So you don't ideally want that matcher to be available to other types of objects like Intes. sense to say, uh, you know, expect one has tag diviv. Um, so I was trying to figure out basically a way to allow you to register matches, uh, With, so you'd say, register this matcher and here's the module. And then also these are the types that I want that module to be applied to. Um, and ideally wanted a way so that when you're using it, you could use that type or any subclass of that type. any subtype. And it would apply. So means basically we need to do a kind of, uh, in ruby we call it a triple equals comparison.

Collin:

Mm-hmm.

Joel:

which is, uh, or case equality, I think it's probably technically called. Um, so if you do, uh, if you say, um, this class is case equal to this object. Then it's gonna compare that that object, um, is either type a subclass of that type.

Collin:

Hmm.

Joel:

anyway, so this would be quite slow. Um, if you can imagine you're running like possibly thousands and thousands of tests, and if every single time that you expect something to happen, have to like go through all the registered matches, types. check whether or not that type, has like case equality with, uh, the type that the matcher was registered for.

Collin:

Yeah, it's like an o n thing, right? You've gotta go through all of them till you find it.

Joel:

it's gonna be really slow. So, um, what we do is we use like a special cache. Um, basically we would do this search only one time for each class, um, and then cache. the matcher that is related to the particular like class that you're testing for. Um, and if you register a new matcher, then it kind of like busts the whole cache up. and it has to rebuild it. But otherwise it's going to, uh, like the second time you do it, it's just gonna use the cached the cached one. And the way that this works in terms of like getting that expectation object. your matcher to be included into is we have like, um, so once you've figured out, you know, for this given, uh, value, has a particular class, these are the matches that should be applied, like that should be available to it.

Collin:

Right.

Joel:

then make an anonymous class and include all of those matches into it. Um, but that anonymous class, again, cached. So for every unique set of matches, as in matcher modules, um, there is like a cached, uh, anonymous class instance. Um, or not instance, but class, instance of class that includes exactly those matches. So you. Are able to like grab the list of matches from, uh, from the cache. You can then check like, do we already have a class that has included specifically these relevant matches? And if we do, just use that one and make a new instance of it. So,

Collin:

Right.

Joel:

I, I hope I've explained that.

Collin:

Yeah, no, that makes sense. So the cost is only the first time you have a class with a set of matchers because then you can cache it and then if another matcher is added later, then you'd have to, you know, redo the cache. Cuz it's invalid.

Joel:

that shouldn't really happen. Like typically like register your matches at like, at startup. Um, but like I've added it in so that if you were to like register a matchup halfway through, it will, it won't break. But typically you just register your matches to begin with. You start running your tests, they start building up their caches, and the, the main cache is like, value, which has this exact class, do we know, um, what matches are relevant to that? And then it's got that list. And then given this big list of matches, we have a class that has included all of them, um, already And like for every, for every unique set of those, there's just gonna be a class that's cached.

Collin:

instead of, so, instead of having this kind of big cost, every time you use a matcher at all, you have this sort of big cost one time in the beginning, and then after that it's just fast.

Joel:

Right. Yeah. And, and what this means, uh, coming back to why, why all of this exists is if I say expect, uh, one, uh, to have tag diviv, it's gonna say, uh, you know, method missing has to have tag doesn't exist. But if I say, expect this Nouri document to have tag diviv, then it's gonna work. because. The class that, the expectation class that I got from one case, uh, included the matcher and the other case didn't. If that makes sense.

Collin:

Yeah. Also because of the way you're using modules for this, uh, a question I had was, can you then do overloading and, you know, for different, uh, matches? So you were saying like it wouldn't make sense for an integer to have has tag, but maybe you, if you had like an XML and you had HTML and they were separate is probably a bad example. You know, they might both have them, but they're actually completely separate. But they would have a matcher called the same thing. Would you be able to do that and figure it out?

Joel:

yeah, I, so I could imagine, um, a couple of examples might have that exact matchup, right? Um, a git repo, they have tags. blog post has tags. Um, yeah, maybe X N L.

Collin:

those are all better examples than I thought of.

Joel:

So you can't, you can't have basically, if you have like, this has tag matcher, for one type and another one's got the same name for a different type, then they will work just fine,

Collin:

Okay.

Joel:

it the right type, it will pick the right matcher. Um, you obviously can't have like two matches with the same name for the same type. Then one of them's gonna win out. But, um,

Collin:

Yeah, but you could, so you could do kind of overloading where like, you know, that you have. That's cool. That's, that's great.

Joel:

And, and I'm trying to make it so that you can really, like, reduce the amount of test boiler plate, by just defining, like, defining a matcher should be something that you can do very easily, uh, and without like a lot of complexity. And the idea is that you could just define matches for your own objects. Um, so You might have a user object and I dunno, this is probably a bad example, but you could just define, uh, you know, for my user object, I want to have this matcher like is admin or something like that. Um, or to be admin. So you can say expect user.to be admin. and the idea is that, uh, you shouldn't have to worry about your custom matches, like either having to import them on a. a particular test file and then just having them available everywhere in that file or having to add them globally and having them available literally everywhere. You can kind of add them sort of globally, but they're only available when it's like the correct type. So they're only available for your user class.

Collin:

Right. No, that all makes sense. I really, I, I. I like green dots. I want to use it. Um, I, I like how simple it is and that it's, there's not much to remember. I love that. I love anything where there's not much to remember. I actually think that's kind of one of the things that really drew me to Ruby is like, it can do a lot, but like the actual toolbox isn't like that extensive for like the basic language. So there's not, there's not that much to remember where a lot of our language is like Swift or Kotlin or like, there's actually just a lot to remember, you know, there's so many ways to do things.

Joel:

When, when you have loads of different ways to do things, I think that can just like make it a lot harder to remember an API or like to work with a new api. Um, I'm trying to make it so that you don't need to think like, is this the next divider? Like if you say like, expect, uh, x to equal to y, you know, that like, do two B or is it two or is it, um, you know, two space, B space EQ, know, it, like a thousand different ways that you could write that in Ruby. Um, I just wanted to make it so simple that you just say expect, um, and then. So you call the method expect and you give it the thing that you're expecting on the value. Um, so say expect a, um, in parentheses, and then you just call one method. So, and that method directly is your matcher. Um, and there's, there's no like chaining methods on methods or like calling a method in the test scope and passing it into the two method, which I think is how our spec does it.

Collin:

Mm-hmm. Yeah.

Joel:

trying to keep it as as simple as possible.

Collin:

Yeah. And also something, are you familiar in kinda user experience design the concept of like progressive disclosure? Have you heard that term before?

Joel:

No.

Collin:

So it's the idea that kind of, uh, actually, so a good example of this I think is a lot of macOS does this really well, but it's basically like you are shown more as you need to know more, right? But in a pretty natural way. So the very basic use of something is very simple. Um, and then everything. And then you are shown more as you need it. And then another, maybe this isn't exactly progressive disclosure, but another, uh, degree for me is that. The things I already know inform the things I don't know yet. And there's a lot of, I think good APIs do this really well where it's like, if you know how to do the basic thing, you know, when you learn something that's maybe in a, you know, maybe even in a different library or something, what you already know kind of informs it. Because there's really strong patterns that tie things together and, um, And that is that, that is something I was thinking about when you were talking about green dots and uh, you know, having things be sort of in a consistent way and an expected way. Right. That's, uh, that like maybe I could sort of predict how this should work, um, where I find the cognitive load of r spec to be pretty high for me. Like I look at it and it's like you said, sometimes it's spaces and there's dots and I'm like, I don't know. There's a lot going on here.

Joel:

Yeah, it's an underscore or or another parenthesis, cuz it's another method called

Collin:

Yeah, so this may not exactly be progressive disclosure. I think it's more like consist a certain kind of consistency. I'm not saying a spec isn't consistent, but I'm just saying like in Mac os, an example I was thinking of is how I was looking at a finder window and I was thinking how do I show the hidden files, right? And I know how to do other, I know like what kinds of commands are used for things like that, right? And I was like, I wonder if it's command shift dot. Because I'm like they're dot files, right? So I type command shift dot and it worked and I could see the hidden files in the thing. Like I didn't have to look that up.

Joel:

mm-hmm.

Collin:

And I think that's because key commands in Mac os like work in such a generally consistent way that I was just able to predict that. And that's just one example. Like this has happened many times. So I really like when things have that sort of internal consistency. Even if it means that in some cases it's going to maybe be a little bit less elegant or whatever than it could be, I would still err on the side of that. Things work in the way I kind of expect them to based on how they have worked in the past with this thing. Does that make sense?

Joel:

Yeah, that, that makes a lot of sense. I think there's, that's ex, that's exactly it. And, um, one, one of the things that you. That you get with like apec, A lot of it's, um, I don't know if Rspec Core has this too much, but, um, there's, there's a lot of like method training, I find to be very difficult. so if you're like expecting something uh, like to receive a method call, you would then chain dot with. pass the arguments and, um, yeah, I, so, um, in Green Dots, instead of doing that, you just, um, like you can expect, uh, something to receive something and instead of chaining dot with and like dot, re dot, um, whatever it is, dot returns or something to say what it should return, can actually just, um, a block. And that block is the method that gets called, it's the stub method. So, um, that block can receive arguments and then you can check whether or not those arguments are what you expected them to be. It can return something if you want to have it return something you, you basically are essentially defining the block that is, that is gonna be. Uh, put on the interceptor, uh, and like put onto that object that you're ex expecting to receive something. Um, you are just like doing a, um, the block for defined method. Um, so that you know about how to use defined method

Collin:

Mm-hmm.

Joel:

like working. Like there, there's no change there. Um, And I just feel like that is, at least for me, a lot simpler than trying to remember this unique, like chaining dsl. Um, I really, yeah, particularly, really struggle with chaining, but there are things about Rspect that I love, um, like I love describe

Collin:

Mm-hmm.

Joel:

Um, and actually I, I, and I love being able to say like, expect. Thing and then pass a match at like two B, whatever. Um, I think that's really nice. Um, rather than having to like kind of swap it around and have, know, methods, like in mini test you would have a, a method, that would, that you would call and then you'd pass it. The two things I think it's nice to, to just cool, expect and pass it the one thing and then pass the, the matcher onto the end of it. I think that's really nice. Um, but like trying to. Reign that in and make it a bit simpler kind of what I'm, I'm trying to do here. And then also, um, one thing that I really struggle with, and I know this is probably just me writing my test wrong, it

Collin:

Mm-hmm.

Joel:

like I, I just can't write tests that work with the, the it keyword. Um, I always end up writing it supports and then just writing the feature as if I had written like test feature.

Collin:

Written like a mini test.

Joel:

Yeah, exactly. So, so Green Dots is kind of like this weird hybrid between mini test and Rspect in a sense. Like we have described blocks and we have test, like test X do, uh, rather than it. and avoiding, uh, Using Let as well. So instead of let, the idea is that you would just use single line method definitions. uh, you can say like, describe thing and then just like def uh, def fo equals whatever, or def bar equals whatever. then you can say Test and then you can reach for foe and bar. cuz every time you say describe you are basically saying subclass the current test. in and make a new one, uh, and then do things in here. So everything that you've said outside of that described block, uh, is kind of like passed down. And then when you go into a described block, you can then override it by adding different things. Um, that kind of allows you to have that, those like methods, kind of like that hierarchy of methods

Collin:

Mm-hmm.

Joel:

and, um, I think that can be really useful. I, I know that that let, does some extra like memorization. um, that's something to think about, but for most, most of the time, I think you can get away with just, just using methods like, um, with single line method definition. Maybe, maybe I'll add let in eventually, but, um, or, or some other way of doing memorization, but yeah.

Collin:

Yeah. But no, I, I like it. I think that's, I think that's great. Um, yeah. In the time that you did, uh, this, I went to r I went to RailsConf then, I drove from Atlanta, Georgia, to now I'm in Minneapolis, Minnesota, which is, I don't know, 1500, couple thousand miles away. It's pretty far. Um but maybe we should talk about RailsConf a little bit. Uh,

Joel:

you're still nowhere near Portland though, right?

Collin:

No, I'm nowhere near Portland. I'm still kind of in the middle of the country actually. I'm just at the northern middle of the country. What I will say is I took different routes cause I wanted to, you know, I was playing, uh, you know, state bingo I guess, or whatever I wanted. I wanted to see the most states. Um, I could for whatever reason. And so there are a couple of different ways you can go. There's probably more than two, but the two that I looked at were, I could go through kind of Highway 80, which goes through kind of the middle of the country, uh, which involved, uh, going up through Idaho and then Utah, Wyoming, Nebraska, Iowa, kind of that direction. And that was the way I went to get to RailsConf and. That was interesting in parts. Um, but a lot of those states are very empty. So like Wyoming is very empty. Uh, Wyoming is a pretty large state and it has in total about half a million people in it, the three largest cities in this entire state. Uh, It only has three cities larger than 30,000 people in it, and the capital of Wyoming is about 60,000 people. So it's like very sparse. Um, and like there are nice things in it, like Cheyenne, uh, the capital of Wyoming, uh, has some nice parts as really cute downtown, but it's very, it is very small compared to, you know, most places. And then,

Joel:

in the entire state.

Collin:

yeah, you should look it up. And it's a, it's not like a small state. I think it's mostly that it is. In my mind, it is similarly sized to Colorado, but the terrain is really not conducive to human habitation in a lot of parts of the state. And so there's really a couple of sort of population centers that people bunch around. And those are in, uh, kind of the, the northwest and the kind of middle southeast of the state. And.

Joel:

There's like 10, there's 10 million people in London,

Collin:

I know it's insane, right? There's like 30 something, you know, there's, there's tens of million people in California. Uh, it's, yeah, so that's a, that, that state was very different. Um, then Nebraska is also empty, but less so, uh, and, and you keep going, um, you know, through Iowa and all of that. So the way you can go that, I'm going back the different way, is on Highway 90. And I gotta say, if you, if, if you ever make this trip, anyone listening, do the Highway 90 way because, uh, it is great, um,

Joel:

Okay.

Collin:

through Highway 90 and maybe it's great that I'm doing, I mean, the other way is nice too, but, uh, going the Highway 90 way is that you, you go through Illinois. So that's where like Chicago is, which was cool. I went to Chicago. I've never been there. Uh, Chicago is like a big city, right in the way, like London, New York is a big city. Um, so I went through that. And then you go through Wisconsin, I knew very little about Wisconsin, right? But I went on this trip saying to myself, I wanna see some, like, what I would call like kitche, Midwest shit. You know, like some like Americana kind of kitche stuff. And it turns out. As far as I can tell, I was mostly just thinking of Wisconsin. Most of that is most of, when you think about like American, Midwest, like funny roadside attractions and things like that, you're mostly thinking of Wisconsin. It's really just there. And I think Minnesota. So right now I'm in Minneapolis, Minnesota, which uh, is the home of Bob Dylan and Prince, uh, and is also great. So Minneapolis and Wisconsin both. Un ironically. Great. I think they're great. So I'm really liking this. Uh, I will go through North Dakota a little bit, which I think is also pretty, uh, sparse. But then I will go through Montana, which is sparse, but also supposed to be extremely beautiful. It's the home of Glacier National Park that you can look up, which is supposed to be amazing. And it's also where, uh, Longtime listeners will or won't know that I, uh, that I play music, and so is also where they build Gibson guitars in a, in a place called Bozeman, Montana. So I'm gonna try and go through there and see if I can talk an employee into, give me a tour of the factory, but we'll, we'll see. So anyway, that's, that's kind of the trip. Yeah. Not that close to Portland yet, but getting closer. I should be back. It's Sunday now. I should be back Tuesday or Wednesday. So a lot of driving. Uh, but RailsConf. RailsConf was great. I I met so many great people. Um, I, I shared a room with our friend from Mastodon, Karl, who, who, you know, um, so he, he was there. He, uh, you know, he, he was great. He's. He has, he has the most positive attitude about everything of any person I've ever met. Like, he just, and I, I am saying this as a compliment. Uh, it just, if you ever, if you ever meet somebody who, who sees something and they're like, this is just the best one of these, this is so great. I'm so excited. Like, he's just so happy to be where he is. It feels like, and I'm, if Karl, if you're listening, I, I know that he is a full, you know, he contains multitudes. I know but when you're at the conference, he just had such a great attitude. Like it put me in a better mood. Like like if I was like, you know, feeling grumpy or whatever, like being around Karl put me in a better mood. Um, cuz he's just that kind of a person. He also did the smartest thing, uh, accidentally, which is that he wore a bright orange beanie. He's like maybe six foot tall. And so it was incredibly easy to find him at the conference cuz he was wearing a bright orange beanie the entire time.

Joel:

Yeah.

Collin:

And on the last day I was like, so did you, did you wear the beanie on purpose? Like that was so smart cuz I made it so easy to, you know, find you And he is like, oh, I just didn't my haircut. I wanna get my haircut. So I didn't, so I wore the beanie. He's like, is that why you keep showing up places? Like he didn't know how I keep finding him. Um, and that was pretty funny. I will say one more thing about Karl, which is that there was a, uh, there was an auction. One of the sponsors was doing for a Nintendo Switch, and this is how good of a person he is. They went to it and the way, because the programmer conference, you go and they say, just make a post request to this api and that's how you enter. And they told him, they said, you can enter as many times as you want, so, If you imagine like, what I think is, I'd be like, cool time to type Aron job, right? Um, I'm gonna win this thing. And Karl said, no, I don't wanna be unfair. I'm gonna enter once. And then he won it.

Joel:

Wow.

Collin:

It blew my mind. I'm like, I don't know, man. Like, yeah, it blew my mind. I also met lots of other great people, uh, Marco Roth, who works on, uh, stimulus and turbo. Um, he's a very quiet guy. He's from Switzerland, so I had fun, uh, because he was a quiet guy. When people were together introducing him by saying, hi, this is my friend Marco. You may not know this, he's probably the best programmer at this whole thing. Uh, and then they would find out like who he was and what he worked on. And um, one guy I introduced him to was a fellow Portlander and I introduced him like that and he was like, oh, great. And then a couple minutes in, he is like, cause I just said Marco, a couple minutes in, he was like, oh, do you know Marco Roth? And he turned his badge around and it said Marco Roth on it, and the guy was like, starstruck. He's like, oh my God. Like he was, yeah, it was amazing. Um, so I I, I'd really love to have him on the show. Uh,

Joel:

Yeah, that'd be great.

Collin:

yeah, I met a lot of great people. There were some really good talks. Um, there, you know, I think what I discovered about this is there, there's a lot of really great talks and I go to them and I watch them and. But I really am big on the, the hallway track, the hanging out part, like that's really what I'm here for. Uh, so it was so, so it was all great. Um, you know, it was good to see everybody. Uh, I am considering Ruby Comp is going to be in San Diego this year, which is a little closer. And I'm, I don't think I'm gonna drive to it because I don't want to do that again, but it is a little bit closer, so I am gonna try and get to that one. Uh, yeah, I don't know what else to say. Atlanta was, Interesting. Didn't get to see as much of it, I think as I would've liked, because it was, um, where they actually put the conference. Uh, this is like my one criticism. This is more of just a like, Fact where they had to put the conference was kind of in the middle of downtown Atlanta and there just isn't really a lot there actually. Like all the cool stuff in Atlanta you wanna see is kind of n not super walkable from there. And so that was unfortunate because I don't know about for you, but when I go to something, I always like that a part of it is that I get to see a new city. Um, but we did get to, I did get to go, uh, you know, get on their local transportation and, uh, And see some other things. So that, that was pretty cool. Yeah, so that was RailsConf, just kind of brain dumping it at you. But, you know, mostly for me it's just, it's great to, to meet so many people, you know, it's, um, it was not as heavily technical really, I would say. It was more just like people hanging out. There were some talks, a lot of the talks were pretty high level. Um, I don't know. It was very enjoyable.

Joel:

Awesome. It sounds like an amazing time. Did, did people go for the, the rooftop ruby stickers?

Collin:

Yeah, actually it was so, um, I was a little bit afraid cause I got like 300 of these things made. I was a little bit afraid I would leave with 290 of them. Uh, and that was not the case. Uh, I met people and if I was like, Hey, you want my stickers? I'd give them to them. And sometimes they just pulled it out and stuck it on their laptop and I was like, oh, that's cool. Um, I was, you know, very exciting for me. Uh, but also I just put them on the tables at Rails Coffee and where people put their stickers and however many I put, they would always be gone the next time I looked. So I was afraid I would come back with like most of them, and I think I handed out at least half of them, uh which in theory means like, you know, double digit percentage of the conference took our podcast stickers, which is kind of crazy. Um, I don't know how they're gonna connect it to being a podcast. Exactly. Some of them. Because it doesn't really say that, but if they search for it, they will. Uh, you know, one, one thing I did, which, which I think is funny, is I decided I'm gonna do like, uh, what'd you call it? Like enforce scarcity or like artificial scarcity. So when I put stickers out, I didn't dump like 30 of them, like some people did, right? I'd put like four and I'd just go back a few minutes later. So whenever anybody looked, I'm like, man, these rooftop ruby ones are really, they're really going. And I think it worked cuz they were always gone when it came back. Um, yeah, I don't know. So, uh, yeah, it's kind of funny. You're like, uh, I updated my library, I did this. I'm like, I don't know. I drove another 1500 miles. Uh, so that's the difference, uh, in our weeks. Um, any other thoughts or anything we want to talk about this week or how we feeling?

Joel:

I think, uh, I think it's good. We, we'd probably get back to like more regular, uh, shows once, once you're back

Collin:

Yeah, for sure. Um, although, you know what, I kinda like it a little loose too. I think I, I think we can br, I think we can bring this experience forward with us and create a hybrid, you know, like really be like, bring some of the, the looseness in. I did tell people as, as a closing note, so I did meet a couple listeners at the, at the, at the, uh, at the conference and when they'd say something, I'd be like, They'd say, uh, they'd say, oh, yeah, you know, love the show, I'd be like, thank you so much. You know, it was very flattering that somebody listened to the show and they found me. Uh, which is also surprising they found me because it's an audio medium. Um, but they did, and that when they did, I would say, well, you know, Joel's really the star of the show. I'm, I'm like, I'm like the funny one, right? Like, I'm like the comedic relief, Joel Joel's really the star. And they'd be like, N no, no. No. And I'd be like, you know, I was, I was joking. Uh, but, um, that, that's why I said whenever somebody did that, um, a lot of people knew you though, whenever I said, oh yeah, I do a podcast, whatever. And they were like, ah-huh. And I'd be like, it's a Joel rapper. And they were like, oh yeah. Like everybody knew you. So, uh, that's, so I think you would have a really good time if you get to come to this next year. Um,

Joel:

It'd be fun.

Collin:

Yeah Uh, you, you could be a real Marco Roth at the show. Um,

Joel:

I'm gonna be going to Brighton. Uh, is it called? Brighton, Ruby

Collin:

Yeah.

Joel:

I

Collin:

Yeah, like June 30th,

Joel:

Yeah. Uh, I'm gonna try and make it out to Ruby Kopf as well, if I can.

Collin:

Yeah. I'm trying to get some things stewing for Ruby comp related to the podcast. So, uh, we'll see how that goes if we have more to announce later. But, um, Anyway, for now, I think this is a great episode and uh, we will put it up and then get back to it when I get back. Uh, so thanks everybody for listening. Uh, if you like the show, please tell your friends post about it on Mastodon or Twitter. You know, neither Joel or I is on Twitter right now, so if you post about on Twitter, you're gonna be exposing us to a whole new group. It's gonna be people like, oh my God, where was this? My whole life? Uh, You know, or rate review, hit the star, do whatever. Um, or just keep listening. That's great too. And we will see you next week the way I said. We'll see you next week. Sounded really like Marco Armit. We'll see you next week. I feel like now the show is over, right?

Podcasts we love