Ivan Nemytchenko is a freelancer. He's a speaker and conference organizer. Ivan spoke at RailsConf about abstract object-oriented programming ideas and how they can be expressed with pictures. The discussion goes into learning processes and how to create visual representations that help people understand Ruby, Rails, or other concepts.

Hey, everyone. Welcome to another episode of Ruby Rogues. I'm David Camira. And today on our panel, we have John Epperson Hello. And Luke Suttters.

Hi. And today, we are talking with a special guest, Ivan Nanchenko. Hi, guys. Thanks for inviting. Yeah.

So do you mind telling us a bit about who you are, some of the things you're working for, and all that good stuff? Of course. These days, I'm freelancer, also consulting from time to time, but, I used I started to use Ruby on Rails in 2,006. And since since then, I was doing a lot of different stuff. I was an owner a cofounder of 2 agencies, organizing conference, speaking a lot, and all the different stuff.

Awesome. So what have you been up to lately? Just some freelance and some consulting. Also, a decent amount of teaching, of course. And we had you come on to talk about one of the talks that you gave at RubyConf called less abstract surprising effects of expressing rules and or of object oriented programming?

Yeah. In a visual way. Yeah. In pictures. In pictures.

Right. So giving us a highlight overview of that talk? Sure. The whole thing started, as a conversation, I guess, a year ago at another conference in Saint Petersburg. And me and some other people who are also involved in teaching, rubies, We were we had a discussion that sometimes it's very hard to explain some abstract concepts to the newcomers.

And there was one rhetorical question which was said. It sounded like, wouldn't it be great if we could illustrate, let's say, dependency injection with just one picture and so that everyone can understand it and understand it in the correct way? So, yeah, that was just a rhetorical question as I said. But later, when I was teaching another pack of students, and I was drawing picture, to them, and those pictures were, like, pictures of little dudes. And those picture were meant to be classes, so I was playing in OOP to them.

And then I, I recall this question, and I thought, what could be, like, the next steps to illustrate more stuff of the OOP in a visual way? And I started drawing, like, arms to those dudes, and I thought, alright. Let's those arms, express methods in our code. And then and more and more and more, and, I I managed to develop some kind of, visual language to express, what's going on in your code. So, yeah, something like this.

I mean, your pictures are awesome. Thank you. Did you come to a conclusion? Did you measure that this works? So in my talks, I was just excited that it all makes sense, despite of the fact that it's it's still all weird.

And I was excited about it and wanted to present this to, basically, to show that. But I think it it was helpful for me, in several ways. First of all, I was able to explain some concepts of OP to my students. Secondly, I was using it in my, freelancing projects as well. So I found it useful when you have some complex, case when you don't know how to model it correctly or you just have some complicated set of glasses when you're solving some specific problem.

What I did is that I let let's say I had 5 or 6 glasses, and I didn't like the design. So I just decided to draw all of them in using this visual language. And from that, I started gaining, like, insights that, like, this, this method is duplicated in in several places and, and so on and so on and so on. So, yeah, it was useful in in my practice as well, but I'm not sure, how to how to share it, with more people and how to make it, more useful. But, yeah, I had some attempts in that as well.

I thought it was a really interesting idea because, a lot of people can do it. You know, just kind of, passing the, dependencies as arguments, but I don't really have an understanding of it. And I think getting that visual model in your head really goes a long way. Do you did you find that the, people reacted well to it? Yeah.

People usually like it a lot because it's a very surprising way of thinking about the code for them. So, yeah, people are really excited, but I don't think many of them find it very practical so far. I assume it's your drawing of the rails mountain, the mountain of learning rails. Yeah. This is, yeah.

I wish I should have told about it. Yeah. This this is a really interesting thing. What is at the top? What is at the top of the rails mountain?

So I would say it's not a rails mountain. It's a cycle, of not a cycle, but, well, let's say life cycle of every rails developer. So, it's it's also another model I developed for another talk, in Ukraine. And, I simply spotted that many of Ruby developers go through the same steps, and I was on many of them as well. So the first step when when you love, Rails, when you believe in Rails way and, you you just fell in love.

Then later on, you started getting some problems and you fixed them with some magic. And after, like, several attempts to fix, stuff with magic, you might get disappointed in real's way. And then you switch to another step where you start learning about all the alternative approaches like solids, dryer b, I don't know, Trailblazer, service objects, and so on. And, of course, patterns. Then, you can, of course, find your, like, spot where you feel comfortable because, like, your projects of a of a specific site, size or or, like, you just found your way of managing complexity in web applications.

But many people, they decide that, alright, something is wrong with the Ruby. Something might be wrong with the with the way we develop, applications. And they starting to leave, and they decided that they should try other, languages, other approaches. And this is step 3. And step 4, like the final, the top of the mountain, is when you manage to learn from all those approaches in different ecosystems.

And you well, on this on this top level, it's actually doesn't matter for you what technology you you use, but you can return to Ruby and you can return to Rails with all this knowledge, and you've broken the matrix. So now you now now you know how to do stuff. So that's the the final step. Yeah. I think for me, getting up to that matrix's broken place, it originally came from me learning Rails before I learned Ruby.

That was probably one of the biggest mistakes that I made. I just dove right into Rails without understanding how Ruby classes work, how to create true, plain old Ruby objects. And so I would have super fat controllers with super fat models. Things were not maintainable. They were not manageable.

I had zero unit tests on my old applications. And I thought that, man, Rails isn't really all that intuitive. It's not all that great. So it really was, hey. Maybe I'm just a bad programmer, which is kinda downing your rails disciple way.

So for me, it was getting up to that peak of the mountain by actually learning Ruby, picking up on some Ruby techniques like memoization or just creating Ruby objects instead of just relying what just Rails provides. So becoming a better Ruby developer made me understand a lot more and become a better Rails developer, essentially. Do you think that people hit that stage faster with Ruby and Rails because it's so good at accelerating you through the early stuff? For me, I I would say no. I was a pretty horrible developer for a long time, mostly because I was just trying to do things by myself.

I wasn't including other people in my work, and that inherently limited me on what I was able to do. So, Yvonne, I feel like I'm seeing a pattern here that you are taking these abstract concepts and putting them into pictures. And for the most part, like, you seem to be getting good reception of it. Like, I myself am connecting with this kind of stuff. I feel like it's kind of analogous to, you know, that maybe that one dude that you know that, like, maybe makes good analogies all the time kinda thing.

I feel like it's kinda like that. Like, that kind of a person tends to be able to maybe it's a skill of a teacher. I I don't know exactly where I'm going with this, but I feel like there's something here, which is I think what you're coming to tell us. They're like, hey. Maybe I don't have a system.

I haven't measured it yet, but but here's the beginnings of 1. Is that where you feel like you are in the process, or do you feel like you're further along? So yeah. I do, I do a lot of teaching. And, like, a a lot of my relatives are teachers, so I I have some some something, something like this.

And, yeah, these these things I'm talking about here and there, they are kind of a part of a bigger system that I have in my mind. And also, I've tried to to write a book. It should called Painless Rails. But, yeah, it's already 2 years after I started writing it, and right now it's in postponed state. But, like, the bigger the big goal for me is to make, development using rails joyful again.

Because I'm a freelancer, I usually I frequently switch from project to project, and I see that a lot of people, they inventing their own bicycles. I mean, remember those times when we had, like, single rails way? When we we were all on the step 1 of this mountain, we all were enjoying the process. And then we started, like, inventing, more approaches because, like, we all grew. Our projects become bigger and more complex.

We needed some other methods to manage complexity, but we ended up having, like, dozens of different approaches, and there is no single unified way of doing that now. I think, ideally, we should have one unified approach again that would fit to 90% of all projects. Of course, like the domain models and, a lot of specifics is different, but I'm still pretty sure that for 90% of 90% of our project for 90% of functionality of 90% of all Rails projects or web projects on Ruby, we can develop a single unified way. Like, imagine if we could measure mathematically, like, a different projects. Like with Trailblazer, we have, a complexity ratio of, I don't know, 5 and, some another metric of, I don't know, 10.

And for another, like, manual rails approach, we have, like, those numbers of 7 and 6, and we could just compare those approaches. And let's say and this this approach is optimal. And while it sounds pretty, like, fantastic, I would say, I still think think it's doable. And I can explain it, but but it it's gonna take some time. So from my perspective, I think that that right there, that motivation to sort of, like, get the I don't know.

That there's I I look at this as sort of being a a platonic thing that there's there's a perfect thing out there, and we're all trying to go get it. Right? We're all trying to seek it. And I feel like that is sort of, like, the motivation that drives, like, half of the things that you see out in the world. You know, somebody's upset about rails, you know.

Now we have, what, Sinatra, Hanami. I mean, they're they're even on your mountain. Right? Like, they're so popular. Trailblazers, not exactly competitor rails so much, but but it's it's competing against, like, pieces of it.

Right? But, like, we have these things where somebody's like, I'm going to try and seek that one thing. Right? Or, you know, in JavaScript world, we have this. Like, we have React now.

We have Vue. Somebody's gonna come up with another, you know, framework. I mean, Angular is kind of, like, sort of on the way, and Amber's basically kind of gone. You know, we're not even talking about the the generation before that. Right?

Like, that are just gone now. Like, people are always, like, trying to recreate this bicycle to achieve that one place. I don't know that we can stop that cycle. I think there's always going to be more churn in the front end than the back end. That wasn't my conclusion, but you're welcome to make that conclusion.

So let let me explain what I mean. Sure. And why I think it's it's achievable, well, at least theoretically. So first of all, this, approach of expressing code in, pictures of little dudes. So what ways to analyze our our code we have right now?

So we have code coverage, for example. We have some complexity metrics with flock or some other stuff with Ruby Critic. But the those are just numbers. And let's say you have a class of 500 lines of code. And, alright, you have a metric that your class has complexity of something like, I don't know, 15.

And that doesn't give you, like, a lot of information you can work with. And, most of the, like, tools give us very low level hints on code quality. And we tend to think that RuboCop, hints are about code quality, but I think those are just about code style mostly. And they can show you that something is wrong, but they can't give you a high level hint. And now, let's say we take, the same class of 500 lines.

And when we try to express it with a picture of little dudes, we can have, like, here's our guy and this guy. So since all the arms are methods let's say we have, 7 methods. So our guy has, 7 arms, and we see like this. And, yeah, in my talk, I was showing, like, the if the method is too long, then the arm is kinda long and wavy. And from that picture, you already see that it's not very good to have such an arm.

It's not very convenient. And for another method, you have, you have 7 arguments there, and 7 arguments are 7 fingers. And the arm with 7 fingers is not convenient also. And, and so on and so on and so on. Like and now you have this class and the properties of the code expressed in one little compact picture, and your brain is actually, well, it, works with with visual objects much better when with the text, and it takes you less time to to understand properties of this picture.

And, actually, there is a thing called churn of faces, and it's used, you can Google for it. And this is a technique when, people used, faces with different expressions to show multidimensional data. For example, you have a table with a lot of columns, and you have to, like, I don't know. It's something like it's showing some death rates or some, information about health in different states. And for example, death rate is expressed with the size of eyes and, like, and I I don't know, something else is expressed with the size of mouth and so on and so on.

So and this uses, parts of our brain which, recognize faces. And with this, you can get very efficient. And this, I found very close this channel faces thing. And, yeah, and what I found that if you use this this in dynamics, so let's say we we have this picture of a 5 100 lines class, and then we get a pull request which changes this class and maybe some others, then we can have another picture. Then this arm is gone.

This arm got 2 2 new fingers, and this arm become longer and and so on and so on. So now you can, like, very compactly, you can see the what differences what high high high level differences were, added to your system. So this is, a So that would be Yeah. A kind of part of some kind of continuous integration system? Yes.

Correct. Actually so two links I've sent to you, the one which called dude's hub. This is a prototype which is developed by my student, which already does that, actually. So you can plug it to your repository, and it will start posting you pictures of those little dudes whenever you create pull request. Does it work on Ruby?

It looks like as a Gemfile and a cat file. Yeah. It should work. I I unfortunately, I didn't have the chance to play with it a lot. And as I said, it's a prototype, but it should work.

K. Awesome. Let's see here. Not sure it looks like an app. Alright.

We'll we'll we'll link it in this stuff or whatever to play with. Oh, yeah. So the the the gem is the last one called Udity, and, Dudeshop is yeah. It's an app. Basically, it should be deployed first to, yeah.

But I think I should just do that so that you could be able to plug it to to your repo. So they work together or something? D u d t is a gem that you can plug to your repository. And, I believe it's a common line utility, and you can say, well, please express these classes as, those pictures of little dudes, and you will get that. Gotcha.

Yeah. Wow. Dude, GL is the Yeah. It's a library of it. Yeah.

It's the core of the whole thing, which actually draws all those, all those Sweet. You this can potentially change, a way of thinking about code complexity. And, of course, it's it's it requires a lot of more research and, I don't know, marketing. Sure. But, yeah, I like it.

So it sounds like what you're arguing here please correct me if I'm wrong. Sounds like what you're kind of making an argument for is that if you, express, your code quality in this visual kind of language, you basically can, do, I think, 2 things. 1, you're cutting down on noise. And 2, you're you're increasing bandwidth because we're using more parts of our brain to help kind of handle this or whatever. So you're communicating with more bandwidth.

Correct. Yes. I mean, the amount of information you can, express in one place is also important. Like, remember that our brain can handle only, like, 7 5 to 7 things in 1, like, byte. Like, here, you because of the compactness, you can place, like, a decent amount of code and analyze it in one place, like, on one picture.

Yeah. And I think that where I like this is the at a glance visual of where things are at. So if I guess one of these little people or dudes as it looks like they're called, if one of them has 10 different arms, that would essentially be, like, like, 10 different public methods that that class has, which in a lot of cases, if you're creating a poro, would not be ideal. So right off the bat, you could say, wow. This class has some serious complexity because you have 10 different entry points to be able to interact with this class.

Maybe we should simplify it so it only has one arm at most 2, and then create other smaller classes to handle whatever the other methods public methods were that this class was originally housing. Correct. Yes. That's a good example. I did similar thing in my talk in, at RubyConf.

I just took, another talk of Sandy Metz where she she was doing exactly that. She took one huge class, and step by step, she splitted it into something like 15 smaller classes. And I, I basically illustrated the whole thing. So and, yeah, you you you can see it in in the talk itself. I mean, kudos to Sandy Metz for, like, kind of basically doing this for so long, like and giving good talks, right, on it.

But, yeah, I I definitely am am coming around to the thing here. Having a visual would make communicating about that stuff a lot faster. Because I think one of the things that I've definitely encountered is that while I have spent a lot of time looking at talks, like Katrina Owen is also really good at this. Right? But, like, watching talks, and reading about stuff, and I feel like I'm pretty good at identifying these things, you know, and I'll comment on them in PRs and things like this.

I feel like it's a very hard thing even for programmers who, you know, we we're like, programmers are smarter than the average bear, and therefore, they should be able to to get this stuff. But, I I think it's a hard concept for everyone. Maybe visual language would help overcome some of those barriers. I know for me, it definitely would. And just take the example, this is kinda like off topic, but related.

But like a, kanban board. A Kanban board usually has 3 columns, to do, doing, and done. And that's great for single flow tasks, tasks that don't require anything other than a to do, doing, or done. You've forgotten the most important column, which is the won't do column. Yeah.

Yeah. If yeah. But, anyways, my problem with that kind of style is that you don't have a great visualization. Okay. So this story that we have now developed this feature on, it's done.

What does done even mean? Does it mean that it has gone through the proper code reviews, that it has passed a QA checkpoint, that, it's been deployed? You know, what does that actually mean? So in a CIACD kind of world, where or a more proper development life cycle world, you have many more steps than just to do, doing, and done. And so I like my boards actually more visual, where you do have several different columns, each column representing the next step for that story.

So you're able to then see at a glance, okay, all of my work is done. There's no more expectations for me this sprint. Why don't I pull something else in or learn something or do something else? So that way, there is no confusion of, oh, the story is done, but it's still actually waiting for code review and waiting to get deployed to our staging environment, something like that. So I see the visual aspect that we're talking about here with the little dudes, being very helpful in not only as a, for new developers, but for seasoned developers to see, at a glance, what is the current situation?

Where are things currently at? How healthy is our actual code? What's what's the status of our actual stories? Just that at a simple glance view, having knowledgeable and actionable information? Yeah.

I think it can be also useful, if you wanna pass the knowledge about some system you're developing and, like, especially of some part of some of some tricky part of the system. Definitely, you can draw it in this way. And then, first of all, you share in this picture, and then you explain what it means. It's like and, yeah, and this way, you can get, like, a more compact way to to to explain things. And I guess you can hope that people will understand it more correct.

I hope that it will work this way. I think so. I I definitely am really into this image thing. I think I also agree with you, Dave. Right?

I agree. I have a a small critique, but I mostly agree about the kanban board thing. As I say, because my kanban board I think everyone has a kanban board that, like, you make a trade off decision between having enough columns to actually capture all the states that you care about. You know, because my combo board is, like, 7 columns big because, you know, I'm focused on well, I I mean How did you get the 7? Alright.

So I have the, like, the needs grooming column. Right? The the actual backlog, you know, then you have in progress. Then I have an in review column, which means that, hey, somebody else is supposed to, like, look at this thing and do, you know, do something. And then there's a ready to deploy column, and then it's completed.

And then, of course, the icebox. Right? Because you can't forget the icebox. Or 7. Okay.

Well, that visually, I have a large screen here and that visually takes up the whole screen. If I'm on my laptop screen, I think the 7th column is hidden. You know? That's not good. Screen can ban board.

Right. But, anyway, so so I'm not trying to get too down and nuts. But my point is there is visual information being drawn from this, but I think it's a stretched prop like, this is a problem where the, the illustration is stretched too far. Right? And I I think that what is making me really comfortable about this code thing is, at least so far, I can't think of a way, right, in which this gets stretched.

Like, I think, Ivan, like, you've captured, basically, most of the problems I can think of. So we're just talking about a high bandwidth communication solution for something that's a problem right now. It's just an easy sell, I think. Yeah. I mean, the potential is enormous.

I Ivan, I really liked your bit in your talk when you talked about the exceptions and how you visualize exceptions as the vomit. Yeah. Basically, things go wrong, and you should understand me that most of the things I haven't even tried to, it was not hard. Like, they really drive you when once you get these basic laws of your universe. Like, you you basically think, alright, and how this thing will look like.

And, like, yeah, it's it's it's obvious now. Like, something front, the guy should want it. That was really evocative. And what immediately occurs to me is some kind of monitoring system combined the concept of the regurgitating exceptions with the dudes, and, you can assign the regurgitations to the dudes so you can see which classes are being physically sick. I did just look through the repo.

There's nothing about failing tests, like and the guy throwing up. This is not implemented yet. But that's my weekend gone. In some ways, this reminds me of a gym that I played around with a while ago, several years ago, rails ERD. But this has a much better at a glance visualization of communicating data and state of your rails application.

So I think it's really cool. I may check this out a bit further. I do have some problems with Ivan. One of the things that struck me as odd was the methods with too many lines of code in them were depicted as swollen arms. So the methods of the arms are ready.

And when they have too many things in them, they become swollen. Correct? Not exactly like this. So if if the method is, is long, then you have a long wavy arm. And your arm gets swollen if there is too many conditional logic in it.

So it it means, like, you get it. Right? It's a complexity score. It's kind of. So because so, basically, this here, it's used to, to demonstrate the nature of complexity.

We this is what, what I came to. So I think, with this with this approach, you can show that there are 2 types of complexity. 1 of one is internal, where you have, like, swollen arms, long arms, and, too many methods and too many internal methods. This is all internal complexity. And external complexity is where you have small, classes, but you have tons of them.

So, basically, the point I was making in the end of my talk after I illustrated Sandy Matt's talk is that complexity actually didn't go away. It just changed the form. So and, so it was all internal complexity. It was all in one single class. And now we have 15, classes, and the complexity is now external.

So we managed, complexity in this way. But sometimes, you can have a lot of classes, but it's too hard to to deal with those classes. So it means you you've gone too far with your OOP or, like, basically design. So that's that's the idea. And, I think that when we are saying that we wanna write in, like, the good code, the whole question is about the balance between internal complexity and external complexity.

So sometimes it's okay to have, like, conditions. Sometimes you have to split it into polymorphic classes, but it's that's up to you to decide. Yeah. I think I think that's kinda what I was hinting at a little bit earlier. Right?

Like, I think it's very difficult for people to actually recognize and know where they've put their complexity. Right? People are really quick to recognize, you know, fat controllers and fat models. But, like, underneath the hood, the reason why fat controllers or fat models bother us is because of, you know okay. I have a ton of conditionals in all of my methods, or I have a million lines in every method.

Right? I'm basically writing imperative code inside my OOP box here. And, maybe there's a different maybe there's a different way to put that. Right? Like, maybe this method is super hard to test or something.

Right? Like, there's a lot of reasons why you might wanna move it out. Typically, I feel like we're like, look, if we can write easy tests, then this is pretty good code, and I can maintain it or whatever. And that's sort of, like, our way to measure that our complexity isn't out of sorts. But, yeah, I I think the reason why this tool is awesome, the way that I'm understanding from you, Yvonne, is it's awesome because it makes it really quick to be able to communicate to somebody else.

This is where all the this is this is how all the pieces lie. Right? Like, okay. There's a bunch of skinny, skinny long arms, or there's a bunch of fat long arms, or there's just fat arms or whatever. Like, I suddenly am giving you a ton of information about where you chose to put your complexity.

Exactly right. And when I'm talking about the optimal way of developing application using some approach, like, let's say, rails, I'm actually talking about this. So we can quantify the way we work. Like, let's say, if we like, every requirement we get from the customer, we, we can quantify in a way, like, here we should add a new entity. Like, here we we have a fork in BusinessLogic.

Here, we have, something else and something else and something else. And let's say we we we've done that. And, also, we can with this visual approach, we can quantify different approaches like trailblazer approach, like dryer b approach, Hanami, and Rails. And, I don't know, Rails plus service objects. For every specific approach, you can say that, alright.

In Rails, I just, threw enough conditioning now in my controller, and I'll be fine. And you can visually see that, alright, this arm got got bigger or got more fat fatter. And with another approach, with Harnani, I've added 1 repository, 1, service, 1 class for my action, and I see that I I've added another kind of complexity. I've added 3 more classes. And this way, you can compare.

So you can see that here we added internal complexity. Here we added external complexity. And now with this approach, we can measure for every typical feature we're developing. Of course, we can, we can we should really simplify this, but for theoretical weights, it it should be enough. So for this way, we get we get, this amount of internal complexity, this amount of external complexity, And we now can now compare those numbers, so whatever those numbers are.

And if we can compare those numbers, we, potentially, we can find this balance. We could find that optimal approach, which would add, optimal amount of internal complexity and an optimal amount of external complexity. This is what I was talking about, actually, when I was start saying that, I think that it is still possible to find an optimal way of managing complexity in Rails applications or whatever web applications in written in Ruby. Well, actually, in any language because it's it's, nothing limits its usage to, to the language itself. Sure.

Assuming we put a value to, like, a dude versus a fat arm, for example. Once we have those values, then we should be able to compare them. Right? So that's what we're getting at here. Right.

Yeah. You basically visualize all the trade offs you're doing. So we you're changing this thing for that thing. This is what you get. It's a fascinating idea.

I still think the the complex methods, if the arms are big, people might like that because they like to have big arms. So they think that these aren't swollen methods. They're kind of muscular methods. Well, if you add few more segments to that arm, you don't like it. You you will not like it that much.

Yeah. Go go look at, go get look at the images on Doo Doo Doo Doo or whatever. They look a lot less like swole arms, and they look more like, I don't know, resistors or, like like, those images those diagrams of, in, like, biology class of, like, the, I don't know, the sheath wrapping around your nerves or whatever whatever that's called. They don't look like full arms. Yeah.

Of course. As I said, it's a prototype. It's a very simplistic pictures. But, yeah, they they still able to express the initial idea, I think. Oh, yeah.

Yeah. Yeah. No. No. No sweat.

I'm not critiquing. I'm saying that I don't think he has to worry about people confusing them for swell arms. I think we're good. Oh, yeah. I think I'm a add this to a project Legit.

Because, I mean, I have a project out there right now that I'm kind of working on. And, you know, I'm running RuboCop, RIC, and Rails best practices on it. And, you know, I mean, it's a pain in the butt to test all 3. Probably need to dockerize the dude's hub thing, but, yeah, I bet we could do I bet we could do this. Yeah.

That would be great. I'll yeah. And please give me some feedback. Cool. Ivan, if people want to follow you and see what you're doing online, where should they go?

So on Twitter, I I'm inem, I nem, I guess. And, yeah, I think it's it's a good point. If you wanna see other stuff I was working on, it's inem dot a ed. So you can see some other projects of mine. And, yeah, that's it.

And probably, of course, my GitHANX, products I was working on as well. Awesome. Let's go ahead and move on to some picks. Luke, do you wanna start us off? My pick, because I've been doing it all week, is, Linode, the hosting company.

I've been watching some of their videos from last year, which was, I think, their 19th anniversary. And the founder was pointing out that Linode is, an older company than Amazon Web Services for cloud hosting. So check them out. Linode, linode dotcom. Awesome.

And, John, do you have any? I do. My first one is is sort of a mix PSA slash, you know, rediscovery, whatever. Back when I was, like, super poor in college, you know, and working out was, like, too expensive. You know?

I I did push ups and sit ups, like, all the time. That was the thing that I did. And, you know, now that you have to be at home, you know, just, like, reminded. I've been doing my push ups and sit ups again. I've actually been doing it for a few months, but but I'm just, like, reminded of how awesome a choice that is since I don't I can't go out to work out anywhere else.

So so yep. That was pick number 1. I've got to ask, how many push ups can you do? How many can I do or how many do I do every day? Because those are completely different numbers.

Well, I I wanna know both the numbers. Okay. Well, I can do about 50 or 60 in one go, which is I don't know. It's okay. God.

You're gonna end up looking with, like, one of Ivan's method people. I feel like if I looked like one of Ivan's method people, it'd be harder for me to do those push ups and sit ups. But, no. I I do I do 20 in 2 sets every day. So because you don't want to go to your limit.

Whatever. Anyway, I should I should be jumping it up to 25 soon, I think, And I'm not feeling it yet. Okay. So the second thing that, I was trying to with my second pick is, so I have an acre and a quarter, and I'm backed up to some woods. And and the whole area around me is very woody and stuff.

So I have lots of brush, things that are hard to mow around. I I live on a hill. You know? So, like, I can't I can't mow that hill, at least not on a riding lawnmower. So I do I have, you know, a a pretty heavy duty weed whacker.

You know, and I've just, like you know, I don't know. I bought the thickest, string that it could handle or whatever. Cool. Great. But it it just what?

I don't know. It just broke all the time and everything. So, anyway, the thing that I'm picking is, like, I bought a head to replace it so that I could not only use thicker string, but that, like, I bought a head that I, I cut off these 8 inch strings and just, like, stick them in instead of having, like, a a reel that that bumps and then, like, I don't know, stops working for whatever reason. Anyway, I've been super happy with the fact that I, like, replaced my head. So I'm not saying you should do exactly what I did, but I, like, looked up online how this stuff worked.

And I came away, bought ahead, replaced it on my weed wacker. And now instead of taking 2 and a half hours, it takes 2. Still a lot of time. Shaved about a half hour, but, like, that's a half hour of, like, me being pissed because my string broke. So, it's totally worth it.

Yeah. It's just been a better experience. So, yeah, I don't know. Find the weed whacker head that works for you. That's that's my pick.

Cool. And, Ivan, do you have any picks? Nope. I actually didn't prepare anything. Okay.

But, well, I would say if you never tried, try using if you're into Versus Code, try using Versus Code remote. I switched to this way of working, like, several months ago. So whenever I start new projects, I no longer, set it up on my local machine. I simply spin up, another virtual virtual server on Cleanout, on Scaleway, some on Amazon and set my stuff set up my stuff there and simply work, using Versus Code remote work as it's in my as it is on my local machine. So if you never tried that, I highly recommend it.

Cool. And I'll jump in with a few picks. So the first spec is the discount code learn from home on a site that I run, Drifter Ruby, which is a series of screen cast. I believe I'm up to over 230 now, so learn from home. And a second pick as far as just talking about code quality and stuff is a pretty cool gem called Reek, which will give you a nice, kinda more of a table visualization similar to what SimpleCov does of all the different code complexity issues that you might have within your application.

And a 3rd pick, which is kind of more of an anti pick, it's a love hate thing, is I've been really diving a lot more into Kubernetes lately, and it's a lot of fun. I've been having some enjoyment doing it and then also a lot of frustration. So that's kind of a pick, anti pick stuff. So We can have another episode on on on that stuff so that you can talk about how your views have evolved or not evolved? Well, so I will say I am working on a pretty cool templating thing that I'm going to start all my new applications, not the ones that I do for directory because I like Kim, though, Slim, but any application that I do personally, it's going to have the Docker Compose and Dockerfile built into the new Rails app.

It's going to then also generate all of the YAML files for deploying that application over to a Kubernetes cluster that has an ingress enabled. So all you have to do is deploy it, and it'll create a whole new environment. So I've been playing around with that quite a bit lately. Cool. But I also I'd give a thumbs up for Wrike too.

I do use it, and I do love it. Right? I just hate having multiple code quality checks in one tool, and I also don't wanna go out there and pay for one either. And I think there's another one called Standard RB, something like that, which will actually do all of the linting changes for you, and it's a pretty safe one. I think test double makes it.

Can't remember. It's been a while since I've seen it. Yeah. I vaguely recall it. I'm just checking out.

It is standard RB. That is the same. Yep. Cool. Alright.

Well, Ivan, I appreciate you coming on and talking with us, and that's a wrap. Thank you, guys. Thanks for winning lights and being Thanks for coming. Yeah. Thanks.

That was really, really interesting.