Rooftop Ruby Podcast

When You See It, You Know It

July 03, 2024 Collin Donnell, Joel Drapper Episode 36
When You See It, You Know It
Rooftop Ruby Podcast
More Info
Rooftop Ruby Podcast
When You See It, You Know It
Jul 03, 2024 Episode 36
Collin Donnell, Joel Drapper

Join the Rooftop Ruby Discord!

Fahrenheit versus celsius? How many degrees fast is a race car?

The new "it" in Ruby, and why do unnamed block parameters start with _1?

We're going to be at Madison Ruby!

Follow us on Mastodon:

Show art created by JD Davis.

Show Notes Transcript Chapter Markers

Join the Rooftop Ruby Discord!

Fahrenheit versus celsius? How many degrees fast is a race car?

The new "it" in Ruby, and why do unnamed block parameters start with _1?

We're going to be at Madison Ruby!

Follow us on Mastodon:

Show art created by JD Davis.

Speaker 1:

We shouldn't do this because we won't be able to start. We already started, so we're starting. Joel, you told me there's a big fight going on the internet about Celsius versus Fahrenheit.

Speaker 2:

Yeah, I haven't really been following it that closely, but I've noticed a bunch of different Celsius versus Fahrenheit memes from programmers and engineers and it's just hilarious. I felt like I had won you over that fahrenheit's superior for humans, though, because I agree that it is closer to a relative like a human relative, like scale.

Speaker 1:

Yeah, that makes sense yeah, like right now it's 71 degrees out and I would be like, yeah, it's like 71, hot it's like 71 percent. Hot percent if it was 100 that's where I'm at like hot, hot, okay, I, I get that. I think they're both useful for different things. If I'm boiling water.

Speaker 2:

Celsius is very useful, so would you. But would you use fahrenheit for cooking?

Speaker 1:

uh, I mean I do because I am in the United States People do right. All of our stuff is in Fahrenheit and I mean you know there's not that many temperatures you use. You know, like when you're baking something it's usually 350, which is whatever that is in Celsius. I don't have a clue what that is in Celsius. Yeah, you don't, but I mean like there's not that many you know temperatures. You don't, but I mean like there's not that many you know temperatures that you use for baking things you know, and if you're making something from a recipe.

Speaker 1:

It'll tell you what it is. I disagree.

Speaker 2:

Depending on what you're cooking it at a certain temperature for a certain amount of time, you're going to get roughly in the right ballpark for it being cooked. But in order to do that you have to really typically overcook stuff, because otherwise you risk undercooking it and, you know, making yourself sick you're talking like meat or stuff like that, yeah, yeah.

Speaker 1:

So I have a little, I have a little thermometer and you stick it in and then it has the temperatures of things like written, you know right exactly so, but those are all different temperatures depending on exactly what it is that you're cooking and how you're trying to cook it so like I don't.

Speaker 2:

I don't know if there is.

Speaker 1:

You said there's like only I was thinking, like for baking, like a lot of stuff is like it's gonna be like 350, it's gonna be like 425, like and if you're making something out of it.

Speaker 2:

I don't even know what these mean, but it's 350 hot yeah, it's really hot.

Speaker 1:

Yeah, so that's like dead hot. Um, yeah, no. So you know, actually when I'm cooking I'll use metric and um imperial. Uh, because, um, grams are really easy for measuring weights of things, huh, because you know they all add up. So I feel like, for weights and measurements like basically everything except celsius and fahrenheit, I I think it's pretty clear that metric is is better I'm just thinking like can you imagine if we, if we measured speed or I don't know, like in the same way that you?

Speaker 2:

you have this like relative measurement for temperature would you? Would you have some kind of like speed measurement? That is, like I don't know, walking would be like 30 and then like running full pellets like 100 yeah, and then like a race car would be like 400, 400 degrees fast I think it would be way more than that.

Speaker 1:

No, it'd be way more um, I think you'd probably want like a logarithmic scale at that point right well isn't.

Speaker 2:

Isn't fahrenheit a logarithmic scale? It certainly feels like it, uh no, I know it's not, no, it's um. It is weird, though, that, um, there are certain points where Celsius and Fahrenheit cross over, like I think positive and negative 40 are exactly the same, or something like that, which is weird.

Speaker 1:

Yeah, I mean, you know math. Yeah, I'm terrible at math, me too. It's funny how many programmers are like I'm terrible at math. Yeah, how's that? I'm terrible at math, me too. It's funny how many programmers are like I'm terrible at math. Yeah, but like everything you do in programming like sort of, is math.

Speaker 2:

It's doing math behind the scenes. I'm not doing math in my head.

Speaker 1:

I mean, like you know, functions and variables like that's all from algebra, yeah. We just don't think about it that way when we're doing programming.

Speaker 2:

But they named them with like single letters. It's like terrible practice, I mean I named my functions.

Speaker 1:

Wait, what Um I mean yeah, Are you excited about it, About, about what it it? Tell me about it.

Speaker 2:

Okay, I'll tell you about it. So in Ruby, when you define a block, you can pick up the parameters for that block, right, and you can name them whatever you want. Or you can not do that and you can use underscore one to refer to the first parameter.

Speaker 1:

underscore two to refer to the first parameter, underscore two.

Speaker 2:

To refer to the second parameter, I don't know why it's not underscore zero, but it's not. It's underscore one. It actually is um, and you should never, ever use that feature. It's terrible. If I read code that has that, I will immediately refactor it and uh and remove it and give those variables names. However, I do think it makes sense when there's only one argument.

Speaker 1:

Yeah.

Speaker 2:

But I hate referring to that as like underscore one.

Speaker 1:

I think that's terrible. Yeah, I remember this. We talked about this, yeah.

Speaker 2:

So Ruby's getting it, which is basically like this implicit if you don't specify the um, the parameters, you're going to be able to just use the word it it's just an alias to underscore one, right, exactly, yeah, um, I guess that's cool, you know, I mean it seems it's, it seems fine.

Speaker 1:

I'm trying to think so. In Swift it's the same, except it starts on zero, so it's backslash zero, and I'll. I'll use that sometimes If, like, I'm doing something where it's just like like map or something you know, yeah.

Speaker 1:

I won't always name the variables, because it's just like you know, multiply slash zero by slash one or whatever. Like I don't need to name those. Um, other than that, I pretty much will always name the variables because it gets confusing to read very quickly. Um, I wonder why they start at one. That's so weird. It's really really weird. I don't, I don't know. Yeah, I definitely prefer it to slash to underscore one.

Speaker 2:

Yeah, yeah, I like it and I think, I think that it's going to take a minute to get used to, but I think it's going to be really, really like beneficial in terms of just like when I, when you see it in the code, you're just gonna know oh, that's the thing that, that's the thing that this thing got yeah, when you see it, you know it you say, or you know when you say, oh god, yeah, it's gonna be terrible to talk about that.

Speaker 2:

Um, I have actually started naming, like explicitly naming the parameters. Well, if there's one parameter I'm operating on for, for like a block, I'll name it it and I want like so that it's a smaller change. When ruby what is it? Three, three, four comes out, it feels like something rubo cop.

Speaker 1:

Should uh have a rule for, like, if you were using underscore one, then like, just change it to it and if you were using.

Speaker 2:

If you're using underscore one, you're evil. I will. Well, yeah, but also then, like, just change it to it.

Speaker 1:

And if you were using if you're using underscore one, you're evil, I will well, yeah, but also they could just change it, like it's a really easy change for them. Um, and also you could imagine the thing you said where, like if you were already calling it it, they could just remove the part where you're passing it in, or whatever yeah, I think.

Speaker 2:

I think you'll be able to do that with reboot cop yeah, that's cool.

Speaker 1:

Um, yeah, so it, that's very exciting. You know, what that reminds me of a little bit is the, the thing from like last year or whatever, where um, the like single line functions. You know I'm talking about where, like the, you can say like death, whatever equals whatever. Yeah kind of reminds me of that where, like you know, know, it's not a big thing, but it's like I guess it's kind of nice to have yeah.

Speaker 2:

Yeah, I kind of. I kind of went I I started using that quite a bit and then I stopped using it quite a bit, like I used to use it for for um, if I ever had any kind of like just method that returns a value, and that was like my rule for when I would want to reach for it. Now I kind of only use it for if I'm defining a method, almost as a way of um, I guess, configuring that class Um, like typically this would be done with a, a class method on some abstract class that you would then call to to pass in some configuration or to declare some configuration and um or like I think you, you might do something like selffoo equals bar in the, in the, in the class level Um, and I think some of that makes sense to be replaced with, like def, foo equals bar. But like for actual normal methods, I kind of like the consistency of a method looking like a method.

Speaker 1:

Yeah, no, if that makes sense. Yeah, that's exactly where I'm at. It's like you can tell when it's appropriate. You know what I mean? Yeah, like, if it feels right, it is right. Yeah, uh, and most of the time I just want a normal method.

Speaker 1:

But if it was like right it was kind of like the thing I was saying with like sometimes I would use the numbers in swift if I was just doing like like a map or something. Yeah, um, like almost the same kind of things you know where. If it was literally just a one line thing, I don't know. I said it. If it feels right, it is right and I think you know when you see it. Yeah.

Speaker 2:

I, yeah, I think I think it's. For me it's. It's usually only if I'm saying like def, foo equals true, right, something super simple like that, that and I've just like throwing at the top of the file. It's like this is just like setting some, setting that maybe some abstract method is going to use.

Speaker 1:

What about if it was returning like true or false, but it was like a ternary kind of thing?

Speaker 2:

no, just you wouldn't do that okay, no, I wouldn't, yeah, I would, personally I wouldn't. Or if it's like assigning an instance variable like no, no, that, that'd be weird. I don't think I would use it for assigning yeah, equals and then equals again on the same line.

Speaker 1:

No, that's gross, um yeah, I could see it. Maybe if it was like you know x times y or something, and then you were just like I could see it for like that um, but I don't know, that actually doesn't come up a lot. Yeah, that that I can think of. So I I can't remember the last time I actually used that um, but I know I have. I just most of the time I just think I default to the other thing because I don't know what about modifiers?

Speaker 2:

uh, have you. So I kind of like the idea of and this is like not a very popular standard um in ruby, um, but like you know how you can like make private methods by putting the word private partway through your class and then any method that's below that becomes private. I kind of like doing private def on the same line, because the def will return a symbol of its name after it's defined and so then private can actually receive a symbol and makes just that method private. And I kind of really like that, because sometimes you run into a method, like you're looking at a method and if you want to know like is this, like what level is this, you have to actually go and look maybe a couple of hundred lines up to find if it's above or below that private tag I feel like that's what most languages I've worked in do.

Speaker 1:

Yeah, like I know, swift does that where you it's like actually on the method, yeah yeah, and I think and you can do it for like variables and stuff too um, I think, I think if you were only gonna have one, yeah, that's, that's the one I would probably go with, because it does make it like it's more verbose, but it's also more explicit. Also, you could mix in your private and you know, if you wanted to be like this private method is called by this public method, like they kind of go together, you could organize your code that way, um, so there are, I could.

Speaker 2:

There's some scenarios I can't think of many where I would want to like, maybe trying to think like if I had some, some module or class um, where, like there was like this pattern that repeated, there was a public method and then a related private method, public method and a related private method. Maybe I would arrange them like that, so I would have the public method and private method that's associated together and maybe a comment above them, and then you'd have, like these groups of pairs. Yeah, but almost all the time what I try to do in terms of like the ordering is I will have the highest.

Speaker 2:

It's really hard to explain this. It's because it's not an exact science, but I try to say the methods that go towards the top of the class, they're the ones that might be called directly. They're the ones that might be called directly. So they're almost always public methods and they are like public methods that you are likely to call on that class, and then below them, like the second order, are methods that are called by other methods. So if you have one public method and it calls another public method, then that should probably go below, and then you eventually get to defining your private methods or your protected methods, um, and ultimately, like this pattern just goes down, like the ones that get called by other ones go below those ones typically, but not directly below them. It's more like they're in a lower hierarchy.

Speaker 1:

Yeah, so not in Ruby. In Ruby I kind of just do what you said, which is why the private and then everything below that's fine for me in Ruby. In other projects I've had, I've definitely had things where it's like you kind of organize them by like functional blocks, where it's like here's the part that is dealing with this and like kind of all, you'll sort of declare all its variables and all its methods and they all kind of are like their own little thing. Yeah, um, and you know, maybe there should be a different thing in that case, but I've definitely seen that probably a different module, that Probably, but in this case they weren't so like I've seen that a lot and that was fine. Also, you know, I think that I think most of the time the default case, what you said, makes the most sense. Yeah, I like it because- Especially if your classes are small.

Speaker 1:

Yeah, Like if they're small that makes more sense.

Speaker 2:

I really like a class to be small, and when I'm reading it from top to bottom, I want the the stuff that I see at the top to give me the most abstract, human readable description of what's going on. And then, as I get further and further down, we're just layering on more and more detail until we get to the lowest level, like actually adding numbers together, fetching things, doing things, um and so, yeah, and I should be able to kind of start at the top and be like, oh, I understand what this entire thing is doing because, um, you know, it's, it's just like do this thing if this other thing or whatever. And those two methods are so well named that I don't need to look at how they're implemented. I can just read them at the top and then, if I want to know, oh, how do we know if we, if we, should do this other thing?

Speaker 1:

I. I can just scroll down like see, maybe a good rule of thumb would be that, uh, if you do feel like you need to start organizing your code in different ways to like, keep it conceptually manageable that this is some like. This has gotten too big and you should be breaking it up.

Speaker 2:

Right, right, and the way to break it up would be um, there's like a bunch of different options. Um, I think your first port of call should be are there any other objects here that like, I feel? Like um, I think of objects as in a sense, they exist before we find them right. In a sense, like that, the, the abstract idea of an object, um, is already there, even if you haven't recognized it yet, even if you haven't given it a name, um, and that like that's pretty. It could be pretty tricky to do, but like, yeah, the best way you can I've found to do that is to look at um, like what, what things tend to go together.

Speaker 2:

Like if I'm calling, if I'm calling a method, and I'm passing a, b and c, and I do that a bunch of times, right, a, b and C end up going to Foo Bar and Baz, right, maybe A, b and C are a thing and I should make a class that models that thing. Right, a, b and C might be, I don't know first name, last name or street address, city, postcodecode, right, and you, we know. Like, obviously, those are easy, you spot those. Okay, I'm going to make an address model, um, but like it could be.

Speaker 2:

You're passing, uh, five different things that describe some permission, right, and so maybe you need a model that is like permissions and you pass in the um, you know the raw value, and then you can ask it questions um, yeah, the other technique that like sometimes you just have an object that just does a lot of stuff, and it's fine that it just does a lot of stuff, like it's a, it's a big object, it's a useful object, and then I think the the the best thing to do to manage that is like what are some themes that I can kind of extract and then try to make modules that encapsulate those themes. And that's where that thing of like grouping, grouping related methods together, I would I would still use that kind of table of contents order, but I would just have them extracted into their own modules that you then include and kind of compose together.

Speaker 1:

Absolutely yeah. I mean, yeah, that is actually what you just said is a really good way that Ruby lets you do it, like the use modules. In that way, what I normally do is make sure I've repeated something at least five times, and if I haven't, I put myself on a performance improvement plan.

Speaker 2:

Yes, yeah, I think that's the most.

Speaker 1:

I think that's the most reasonable way to handle it. Um, no, that'll make sense. So I guess we're going to Wisconsin. Yeah, yeah, that's for Madison, ruby, yes, we are. When I was on my big road trip and I don't know if you have this picture of America because you're not in America, but in my mind there's kind of a sort of kitschy Americana like you know, roadside diner, roadside attraction sort of you know what you think of with you know that kind of Americana stuff. And my experience was that, driving through all these states, it was almost all just in Wisconsin. So I got to Wisconsin and then all of a sudden all that stuff I'd been kind of looking for was there. Yeah, so I'm excited to go back to Wisconsin. I've never been to either of the like Madison, which I think is the college town, or the other, the other big one in Wisconsin, which is called Milwaukee. I've never been to either of those. So that will be exciting to see. Yeah.

Speaker 2:

Yeah, I've never been either. I mean, I've spent very little time in the US, to be honest, mostly for Ruby conferences, which is great, gets me traveling. But yeah, so we're going to Madison, we'll both be there. And if you're coming you should definitely Not you, you, listener, listener, dear listener, if you are, are coming, you should send us a message and we will, um, definitely try to uh, meet, meet up somewhere. I'm not sure what if we're doing like a, an official rooftop ruby party that was.

Speaker 1:

That was very stressful. That was quite a lot that was very stressful for that was quite a lot.

Speaker 1:

That was very stressful for me. Yeah, the thing that's crazy is that I was looking at it and it seems like the closest airport so Madison. Yeah, madison only has a regional airport. So to fly from Portland to there it's like six and a half seven hours because you have to stop somewhere else. It's like six and a half seven hours because you have to stop somewhere else. So the closest major airport is Chicago, which is like 107 miles from Madison, which is pretty far. So now I want should I drive? No, I don't want to do that again, but I wonder how long it would take, it would take me roughly.

Speaker 1:

Oh no, it's really far. I just realized like that's almost the whole trip. Actually. That too, I'm not doing that, so I'll be flying too much, and then I guess maybe I'll rent a car in chicago um so we'll figure that out. Um, yeah, so that's exciting, uh, and then, and then you're going to brighton ruby tomorrow yeah, so brighton ruby is on friday, um, but I'm going up tomorrow.

Speaker 2:

like people tend to arrive the day before and then there's like usually something happening in the evening, like not like formally arranged anywhere, like, but there's just like we tend to end up just hanging out British pubs and that the Red Lion the old you know the old Scotch and Dodger whatever you call it, there's probably about 50 Red Lions just in Brighton.

Speaker 1:

Yeah, it's the most common name for a pub.

Speaker 2:

Yeah, so yeah, I'm going there. I'm also going to yuriko, if that's how you pronounce it, yuriko, yuriko, I don't know if you're gonna be able to make it. When is it awesome if you could?

Speaker 1:

um, it's in september uh, probably not, but um, we'll see how things are going, uh, next month, but um, maybe. Uh, that's a pretty long flight, um, yeah, and you keep coming to me, so why would I need to right exactly?

Speaker 2:

yeah, um, oh. Speaking of, um, like meeting up with people, we promised in the last show, which was a very, very long time ago, yeah, that we would start a discord, so I think we're actually going to do it this time.

Speaker 1:

And hopefully.

Speaker 2:

I'm going to say that I'm going to have a Discord set up before this show goes out. Perfect, yeah, and then I can break another promise.

Speaker 1:

Yeah, I agree, I like anything where you do it, so I think that sounds perfect. I'll have to make sure the Discord apps on my, on my Mac I don't know, I don't use that one very often. Let me think what else is going on.

Speaker 2:

Well, so we haven't put out an episode.

Speaker 1:

In a few months, many, many months, but you're. You're building a podcast studio, so it'll be easier, but you're building a podcast studio, so it'll be easier.

Speaker 2:

Right, exactly, yeah, so the problem is I got a new job and it's for an American company. So basically the time when the very little overlap time that I had with Colin uh would be like where we could record these shows, I've just been like trying to meet up with people and like get to know my, my new role, Um and um outside of that, like it's typically too late, Um late because I have to work in the living room, which is kind of like insane. But yeah, I'm getting a new office slash studio, podcast studio. It's going to be amazing and, yeah, hopefully it's going to be better audio quality and easier to make these things going forward.

Speaker 1:

Yeah, no, I think well, we should make a point to try and have some kind of a schedule, even if it was like every other week right now, right, and then hopefully, when you get the studio done, it will be a little easier. Back to the regular yeah, come up to. Yeah, and I don't know, you brought all the topics this week. I need to come up with some good topics. Like I said, I've been doing so much. I've been doing so much music stuff. That's like all I've been thinking about booking shows and working on recordings.

Speaker 1:

Oh, I had to make a little band website for myself, which isn't that interesting. There's not really anything on it, it just has, like where I'm playing. But I have been debating. I'm like should I just make a Ruby app for this? Like you know, cause it asked? I mean it could even just be a static website, but you know it has a few things. It has kind of a static main page. That is like you know, I don't know a picture of me and maybe like Build your own CMS, let's go. Yeah, I mean it would be.

Speaker 1:

I think it would not be a general purpose CMS, so I think that makes it easier. Like it is literally just for my thing, and I'm kind of debating it. I probably shouldn't. My feeling, though, is that, you know, as far as like the website making things out there, there's a couple, and there's one called like Bandzoogle, which has been around forever, and it's like Squarespace, but just for bands, and it's pretty cool, except for that all their templates are really ugly, in my opinion. I don't like their templates very much. And then Squarespace has great templates, but there's always something with Squarespace that is like this would be great except for there's this one decision they made that I find very frustrating.

Speaker 2:

You know so my experience with squarespace has been very negative, to be honest, yeah, and we're not spot, we're the one episode, the one podcast in your uh, in your feed that's not actually sponsored by squarespace. So we could say this I think, I think if you're building.

Speaker 1:

I think if you're building a certain kind of thing, it would make a lot of sense like if you were a bar or like a restaurant and maybe you have like some events. I think it makes a lot of sense for that, because they just sort of have all of that built in for you, um, and it also is very easy to customize like something and um, it may.

Speaker 1:

You know, they're always updating that thing, so it had definitely changed a lot since last time I looked at it. One thing I like what I like on theirs is that it's just a grid, so you can just drag things around and you've got a grid that they snap to. Yeah, um, where? On a lot of these things, I feel like the um, what is it the? The fact that they are using, like you know, different, you know, like flex or css grid or whatever kind of like, like the data model sort of sneaks through, and so it's like you have to add a section and a section can have a certain number of columns and you can kind of see it where. I do like that with the Squarespace thing, but I probably still won't use it, so I don't know. I'll give an update on that. Maybe I should make it with Ruby so that we have something to talk about.

Speaker 2:

I think you should build it from scratch Hand code that.

Speaker 1:

Thing.

Speaker 2:

Yeah, the problem is I I need to make the design look good too, though. So, like taylor, just tailwind.

Speaker 1:

Yeah, I don't know if tailwind says band though you know, tailwind kind of says like e-commerce website, uh, where I really want to say like rock and roll, um yeah, but maybe I will play with this this weekend, just so we have something to talk about on the next episode, uh so Okay, do you remember customizing MySpace? I do. I think a whole generation of millennials uh learned HTML for the ability to customize MySpace, which is very, very cool.

Speaker 2:

I don't know. I feel like I feel like we missed some of that, like everyone. Like people don't have like a space online that's their cut. Like it's definitely way more amongst developers, but like even I don't have anything that's like. It's like my. I don't have a website that I've customized. I feel like I should. It's just. I know that it's one of those things that it's like a massive time sink for a lot of people like me and I know it would be a massive time sink for me if I did it.

Speaker 1:

Yeah, um, but yeah, yeah, it definitely is um, which is why I don't want to go that route, but at the same time, um. You know, the one thing about myspace is that's a really good name for what it was.

Speaker 2:

Uh, they really nailed the name, yeah I kind of wish I could just customize my Twitter profile with CSS. Yeah, there was actually. I don't know if they fixed it yet, but there was a bug in GitHub that meant that you could inject CSS into your readme, which is pretty cool. I think they must have fixed it. I don't know because I I I made the flex readme have this thing. Um, I'm gonna check it right now live see if they fixed it.

Speaker 1:

Ah, such a shame it looks so cool yeah yeah, I feel like there was MySpace and then Tumblr. I think kind of had some of that energy too, and now everything. Now I think you can't really customize, it's all just sort of what it is.

Speaker 2:

Tumblr. Let you change the colors. I think right, but they didn't let you really change.

Speaker 1:

I think you could. I mean you could make your own theme if you wanted to. Could you? Yeah, you could.

Speaker 2:

I mean you could make your own theme if you wanted to. Um, could you?

Speaker 1:

yeah, yeah, you could make like a full tumblr custom theme like you can for wordpress, um, but anyway, um, yeah, I don't know. Seems like a show, so, uh, so we want to try and do this again next week and you're going to set up a discord yeah, yeah, we need to get.

Speaker 1:

We need to get back into it okay, let's get back into it season two, season two, and let's, um, I'm gonna figure out how I'm gonna get to madison wisconsin, so I'll we'll let you know. Maybe you should, maybe we should both try and fly in chicago on the same day and then I'll just rent a car and yeah, it'll be easier, um, because I feel like getting to that weird regional airport's gonna be kind kind of weird, kind of hard. Anyway, all right, cool. Well, thanks everybody for listening. We will see you next week or the week after, probably, or maybe in like six months. No, it'll definitely be before then.

Temperature Measurement and Programming Discussions
Organizing Methods in Code
Travel Plans and Podcast Studios

Podcasts we love