Hey, everyone, welcome to another episode of Ruby Roaks. I'm David Kimura, and today on our panel we have John Epperson, Hello, and Luke Sutter's Hi. And today we are talking with a special guest, Yvonne named Chenko.
Hi. Guys, thanks poin 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 started to use Ruby and reels in two thousand and six, and since then I was doing a lot of different stuff. I was an owner, a co founder of two 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 is amount of teaching, of course.
And we had you come on to talk about one of the talks that you gave a Ruby comp called less Abstract Surprising Effects of expressing rules and or of object oriented programming.
Yeah, in a visual way, uh, in pictures in pictures, right?
Would you mind.
Giving us a highlight overview of that talk?
Sure?
The whole thing started as a conversation. I guess a year ago. It's another conference in Saint Petersburg and me and some other people who are also involved in teaching rubists, 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 be great if we could illustrate let's say, dependency injection with just one picture and so that everyone can standard 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 tacke of students and I was drawing picture to them, and those pictures were like pictures of little dudes, and those pictures were meant to be classes. So I was playing in OP to them, and then I recalled this question, and I thought, what could be like the next step to destrade more
stuff of the OP in a visual way. And I started drawing like arms to those dudes, and I thought, all right, let's those arms express methods in our code.
And then and more and more and more, and.
I managed to develop some kind of visual language to express ask what's going on in your code.
So yeah, something like this.
I mean, your pictures are awesome. 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 still all weird, and I was excited about it and wanted to present this basically to show that. But I think it was helpful for me in several ways. First of all, I was able to explain some concepts of few 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 classes when you're solving some specific pro What I did is that I, let's say I had five or six classes 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, uh, this method is duplicated 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 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 when your head really goes a long way. Did you did you find 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 as you're during the rails mountain, the mountain of learning rails, Yeah, this is a yeah, I should chat about it. Yeah, 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 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 you love rails, when you believe in Rail's way and you just fell in love.
Then later on you started getting some problems and you fix them with some magic, and after like several attempts to fix stuff with magic, you might get disappointed in rails way. And then you switch to another step where you start learning about all the alternative approaches like solid dryer, be I don't know, trail blazer service objects and so
on of course patterns. Then you can, of course find your spot where you feel comfortable because like your projects of a specific size, or like you just found your way of managing complexity in web publications. But many people they decided that all right, something is wrong with the Ruby, something might be wrong with the way we develop applications, and they started to leave and they decided they should
try other languages, other approaches. And this is step three and step four, like the final the top of the mountain is when you managed to learn from all those approaches in different ecosystems and.
You well on the top level.
It actually doesn't matter for you what technology you use, but you can return to Ruby, and you can return to Rails with all this knowledge, and you've broken the metrics, so now you know how to do stuff.
So that's 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 worked, 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 kind of down in 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 minimalization, 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 Else 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 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 Von, 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 it makes good analogies all the time kind of thing. I feel like it's kind of like that, like that kind of a person tends to be able to Maybe it's a
skill of a teacher. 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 like, Hey, maybe I don't have a system, I haven't measured it yet, but but here's the beginnings of one 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 lot of my relatives at teachers, so I have some something something like this, and yeah, 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 write a book. It should called Painless Rails. But yeah, it's already two 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 switched 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 were all on the
step one 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's no single unified way of doing that. Now, I think ideally we should have one unified approach again would feed to ninety percent of all projects. Of course, like the
domain models and a lot of specifics is different. But I'm still pretty sure that for ninety percent of ninety percent of a project, for ninety percent of functionality of ninety percent 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 a progress like with Trailblaser, we have a complex situatio of I don't know five, and some another metric of I don't know ten, and for another like wul rails approach, we.
Have like those numbers of.
Seven and six, 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 it's doable.
Man, I can explain it, but 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 look at this as sort of being 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 Anami. I mean, they're even on your mountain, right, like they're so popular. Trailblazer is not exactly competitor rails so much, 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 you. Somebody's gonna come up with another, you know framework. I mean Angular is kind of like sort of underway, and Ember is basically kind of gone.
You know, we're not even talking about.
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 me explain what I mean sure, and why I think 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 code we have right now? So we have code coverage, for example, we have some complexity metrics with flog or some other stuff with.
Rugby Critick, but those are numbers.
And let's say you have a class of five hundred lines of code, and alright, you have a metric that your class has complexity of something like I don't know, fifteen, and that doesn't give you like a lot of information you can work with.
And most of.
The 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't show you that something is wrong, but they can't give you a high level hints.
And now let's say we take the same.
Class of five hundred lines and when we try to express it with the picture of little dudes, we can have like here's old guy and this guy.
So since all.
The arms are methods, let's say we have seven methods. So our guy has seven arms, and we see like this, and yeah, in my talk, I was showing like the if the method is to loan, then the army is kind of lone and wavy. And from that picture you already see that it's not very good to have such an army.
It's not very convenient.
And for another method you have you have seven arguments there, and seven arguments are seven fingers, and the army with seven fingers is not convenient also, and so on and so on and so on like and now you have this class and the properties of the code expressing in one little compact picture, and your brain is actually, well, it works with visual objects much better when with the text, and it takes you less time to understand.
Property of this picture.
And actually, there is a thing called channal faces, and it's used.
You can google for it.
And this is a technique when people used faces with different expressions to show multi dimensional 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 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 channal faces thing. And yeah, and what I found that if you use this in dynamics.
So let's say we we have this picture of a five one hundred 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 two new fingers, and this arm.
Become longer, and so on and so on.
So now you can, like very compactly you can see what differences, what high high level differences were added to your system.
So this is so that would be 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 dudes up. This is a prototype which is developed by my student.
Which already does that.
Actually, so you can plug it to your pository and it will start posting you pictures of those little dudes.
Whenever you create full request?
Does it work on Ruby? It looks like as a gem f on a cat file.
Yeah, it should work. 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.
Okay, awesome, let's see here. I'm not sure it looks like an app. All right, well we'll link it in the stuff or whatever you play with.
Oh yeah, so the gem is the last one called Judity and Dude's tap 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 your report.
Should they work together or something?
Is a gem that you can pluck 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 nets and you will get that.
Gotcha?
Do gl is the Yeah, it's a librariation of it. Yeah, it's the core of the whole thing which actually draws all those Uh. This can potentially change a way of thinking about code complexity, and of course 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 two things. One you're cutting down on noise, and two 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 seven five to seven things in one bite like here.
Because of the compactness, you.
Can place like a decent amount of colde and analyze it in one place 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 looks like they're called, if one of them has ten different norms, that would essentially be like ten 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 ten different entry points to be able to interact with this class. Maybe we should simplify it so it only has one arm at most two 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 a trubconf I just took another talk of Sandy Mats where she was doing exactly that.
She took one huge class and step by step.
She splitted it into something like fifteen smaller classes, and I basically illustrated the whole thing.
So and yeah, you can see it in the talk itself.
I mean kudos to Sandy Metz for like kind of basically doing this for so long and giving good talks
right on it. But yeah, I definitely am am coming around to the thing here that 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've 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 and prs and things like this. I feel like it's a very hard thing, even for programmers, who you know, we were like, oh, programmers are smarter than the average bear, and therefore they should be able to get this stuff. But 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 kind of like off topic but related, but like a con bond board, a combine board usually has three 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.
The most important column which is that won't do column.
A 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 is 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 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 board's 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 a 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 season developers to see at a glance, what is the current situation where 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 want to 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're sharing this picture and then you explain what it means, 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's more correct.
I hope that it will work it this way.
I think.
So I definitely am really into this image thing. I think I also agree with you, Dave right.
I agree.
I have a small critique, but I mostly agree about the combon board thing, as I say, because my combin board, I think everyone has a common 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 combon board is like seven columns big, because you know, I'm focused on.
Well, how did you get the seven?
All right?
So I have the like the needs grooming column right, 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 there's it completed, and then of course the ice box, right, because you can't
forget the icebox or seven. 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 seventh column is hidden. You know, it's not.
Good screen can board.
Right, But anyway, 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 illustration is stretched too far right, And 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, Yvon, 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 cell, I think.
Yeah, I mean the potential is enormous. Ivan. I really liked your bit in your talk when you talked about the exceptions and how you visualize exceptions as a vomit.
Yeah, basically things go wrong, and you should understand me that most of the things I haven't tried to it was not hard. Like they really drive you when once you get these basical laws of your universe, like you basically think, all right, and how this thing will look like, and like, yeah, it's it's it's obvious.
Not like something woman that was really evocative. And what it 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.
It's not implemented yet.
But that's my weekend gun.
In some ways, this reminds me 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 rail's application. So I think it's really cool. I may check this out a bit further.
I do have some problems with it. Ivan wonder. 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 already and when they have too many things in them they become swollen.
Correct, not exactly like this.
So if the method is long, then you have a long wavy arm. Your arm gets swollen if there is too many conditional logic in it.
So 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 demonstrate the nature of complexity. This is what I came to. So I think with this, with this approach, you can show that there are two types of complexity. One 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 send them stock 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 fifteen 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 still hard to deal with those classes, so it means you've gone too far with
your OPO, like basically designed. So that's the idea, And I think that when we are saying that we want to 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 that's up to you to decide.
Yeah, I think I think that's kind of 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 for 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 op box here, And uh, 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 want to move it out. And 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 think the reason why this tool is awesome the way that I'm understanding from you, Yvon, 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 skinning skinny long arms, or there's a bunch of fat long arms, or there's just fat
arms or whatever. Like I suddenly I 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 it's 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 business logic. 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 be approach, Hanani and rails and I don't know,
rails plus service objects. For every specific approach, you can say that, all right, in rails, I just threw another condition in my controller and I'll be fine, and you can visually see that, all right, this arm got got bigger or got more fat fatter. With another approach, with Hanani, I've added one repository, one service, one class for my action. And I see that I've added another kind of complexity.
I've added three more classes. And this way you can compare, so you can see that here we added internal complexity. Here we are 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 ways, it should be enough. So for this way, we get this amount of internal complexity, this amount of external complexity, and we 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 an optimal amount of internal complexity and optimal amount of external complexity.
This is what I was talking about actually when I was saying that, I think that it is still possible to find an optimal way of managing complexity in Reil supplications or whatever, web applications, in written and ruby, well actually in any language, because it's nothing limits its usage to the language itself.
Sure, I mean we put a value too, like a dude versus a fat arm, for example. Once we have those values, then we should be able to compare them.
Right. Is 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 a few most segments to the term, you don't like it, you don't, you will not like that much.
Yeah, go look at uh go get look at the images on digity or whatever. They look a lot less like swollen 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 sheets wrapping around your nerves or whatever whatever that's called.
It don't look like small arms. Yeah.
Of course, as I said, it's a prototype. It's a very simplistic pictures.
But yeah, they're still able to express the initial Leadzier.
I think, oh yeah, yeah, no, No, that's what I'm not critiquing. I'm saying that I don't think you have to worry about people confusing them for small arms.
I think we're good.
Yeah.
I think I'm gonna add this to a project legit, because I mean, I have a project dot there right now that I'm kind of working on, and you know, I'm running Rubacopriek and Rail's Best Practices on it, and you know, I mean, it's a pain in the butt to test. All three probably need to doc rize the dude's hub saying, but yeah, I bet we could.
I bet you could do this.
Yeah, that would be great. Yeah, and please give me some feedback.
Cool. If if people want to follow you and see what you're doing online, where should they go?
So on Twitter? I I am, I an E m IM.
I guess and yeah, I think it's it's a good point. If you want to see other stuff I was working on at im dot as so you can see some other projects of mine, And yeah, that's it's probably of course my tungus bro I was working on as well.
Awesome. Let's go ahead and move on to some picks. Luke, do you want to 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 nineteenth anniversary, and the founder was pointing out that Linode is an older company than Amazon Web Services for cloud hosting, so check them out linodelinode dot com.
Awesome, And John, do you have any I do?
My first one is it's sort of a mixed 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 did push ups and sit ups like all the time. That was the same 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 one.
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 want to note both the numbers.
Okay, well I can do about fifty or sixty and one go, which is I don't know, it's okay, God.
You're going to end up looking like one of the Ivans Method people.
I feel like if I look like one of Ivan's method people would be harder for me to do those push ups and sit ups.
But no, I I do.
I do twenty in two 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 twenty five soon, I think, and I'm not feeling it yet. Okay, So the second thing that I was trying to but my second pick is so I have an acre and a quarter and I'm backed up to some woods 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 live on a hill, you know,
so like I can't. I can't mow that hill, at least not on a riding lawn mower. So I do I have, you know, 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 whatever. Cool, great, but it's 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 sticker string, but that like I bought a head that I cut off these eight inch strings and just like stick them in instead of having like a reel 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 whacker, and now instead of taking two and a half hours, it takes two 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 my pick.
Cool and avone, Do you have any picks?
Nope, I actually didn't prepare anything. Well.
I would say if you never tried, try using If you're into vs code, try using viscode 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 server on clean Ote, on Scaleways on Amazon and set my stuff, set up my stuff there and simply work using Visco Remote work. As it's in my log 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 pick is the discount code learn from Home on a site that I run, Drifting Ruby, which is a series of screen cast believe I'm up to over two hundred and thirty now, so learn from Home.
And a second pick as far as just talking about code quality and stuff, is a pretty cool gym called reek, which will give you a nice kind of more of a table visualization similar to what simple cub does of all the different code complexity issues that you might have within your application. And a third 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.
So have another episode 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 dritchery, because I'll like Kumudo slim, but any application that I do personally, it's going to have the doctor composed and doctor file built into the new rails app. It's going to then also generate all of the YAMO 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 they'll create a whole new environment. So I've been playing a round with that quite a bit lately.
Cool. But also i'd give a thumbs up for Riek two. I do use it, and I do love it. Right.
I just having multiple code quality checks in one tool, and I also don't want to go out there and pay for one to either.
And I think there's another one called standard RB something like that, which will actually do all of the linking changes for you, and it's a pretty safe one. I think test double mates. 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 IV that is the same yep.
Cool?
All right, well, Ivine, I appreciate you coming on and talking with us, and that's a wrap.
Thank you guys, thanks swimming lights and me.
Thanks for coming.
Yeah.
Thanks, that was really really interesting.