Speaker 1: Hey, everyone, welcome to another episode of Ruby Roaks. I'm
Speaker 1: David Kimura, and today on our panel we have John Epperson, Hello,
Speaker 1: and Luke Sutter's Hi. And today we are talking with
Speaker 1: a special guest, Yvonne named Chenko.
Speaker 2: Hi. Guys, thanks poin inviting.
Speaker 1: Yeah, so do you mind telling us a bit about
Speaker 1: who you are, some of the things you're working for,
Speaker 1: and all that good stuff.
Speaker 3: Of course, these days, I'm freelancer, also consulting from time
Speaker 3: to time. But I started to use Ruby and reels
Speaker 3: in two thousand and six, and since then I was
Speaker 3: doing a lot of different stuff. I was an owner,
Speaker 3: a co founder of two agencies, organizing conference, speaking a lot,
Speaker 3: and all the different stuff.
Speaker 1: Awesome. So what have you been up to lately?
Speaker 3: Just some freelance and some consulting. Also is amount of teaching,
Speaker 3: of course.
Speaker 1: And we had you come on to talk about one
Speaker 1: of the talks that you gave a Ruby comp called
Speaker 1: less Abstract Surprising Effects of expressing rules and or of
Speaker 1: object oriented programming.
Speaker 3: Yeah, in a visual way, uh, in pictures in pictures, right?
Speaker 2: Would you mind.
Speaker 1: Giving us a highlight overview of that talk?
Speaker 2: Sure?
Speaker 3: The whole thing started as a conversation. I guess a
Speaker 3: year ago. It's another conference in Saint Petersburg and me
Speaker 3: and some other people who are also involved in teaching rubists,
Speaker 3: we were we had a discussion that sometimes it's very
Speaker 3: hard to explain some abstract concepts to the newcomers. And
Speaker 3: there was one rhetorical question which was said. It sounded like,
Speaker 3: wouldn't be great if we could illustrate let's say, dependency
Speaker 3: injection with just one picture and so that everyone can
Speaker 3: standard and understand it in.
Speaker 2: The correct way.
Speaker 3: So yeah, that was just a rhetorical question, as I said.
Speaker 3: But later when I was teaching another tacke of students
Speaker 3: and I was drawing picture to them, and those pictures
Speaker 3: were like pictures of little dudes, and those pictures were
Speaker 3: meant to be classes. So I was playing in OP
Speaker 3: to them, and then I recalled this question, and I thought,
Speaker 3: what could be like the next step to destrade more
Speaker 3: stuff of the OP in a visual way. And I
Speaker 3: started drawing like arms to those dudes, and I thought,
Speaker 3: all right, let's those arms express methods in our code.
Speaker 2: And then and more and more and more, and.
Speaker 3: I managed to develop some kind of visual language to
Speaker 3: express ask what's going on in your code.
Speaker 2: So yeah, something like this.
Speaker 4: I mean, your pictures are awesome. Did you come to
Speaker 4: a conclusion, did you measure that this works?
Speaker 3: So in my talks, I was just excited that it
Speaker 3: all makes sense despite of the fact that it's still
Speaker 3: all weird, and I was excited about it and wanted
Speaker 3: to present this basically to show that. But I think
Speaker 3: it was helpful for me in several ways. First of all,
Speaker 3: I was able to explain some concepts of few to
Speaker 3: my students. Secondly, I was using it in my freelancing
Speaker 3: projects as well, so I found it useful when you
Speaker 3: have some complex case when you don't know how to
Speaker 3: model it correctly, or you just have some complicated set
Speaker 3: of classes when you're solving some specific pro What I
Speaker 3: did is that I, let's say I had five or
Speaker 3: six classes and I didn't like the design, so I
Speaker 3: just decided to draw all of them in using this
Speaker 3: visual language, and from that I started gaining like insights
Speaker 3: that like this, uh, this method is duplicated in several places,
Speaker 3: and and.
Speaker 2: So on and so on and so on.
Speaker 3: So yeah, it was useful in in my practice as well.
Speaker 3: But I'm not sure how to how to share it
Speaker 3: with more people and how to make more useful. But yeah,
Speaker 3: I had some attempts in that as well.
Speaker 5: I thought it was a really interesting idea because a
Speaker 5: lot of people can do it, you know, just kind
Speaker 5: of passing the dependencies as arguments. But I don't really
Speaker 5: have an understanding of it, and I think getting that
Speaker 5: visual model when your head really goes a long way.
Speaker 5: Did you did you find the people reacted well to it?
Speaker 2: Yeah?
Speaker 3: People usually like it a lot because it's a very
Speaker 3: surprising way of thinking about the.
Speaker 2: Code for them.
Speaker 3: So yeah, people are really excited, but I don't think
Speaker 3: many of them find it very practical so far.
Speaker 5: I assume as you're during the rails mountain, the mountain
Speaker 5: of learning rails, Yeah, this is a yeah, I should
Speaker 5: chat about it. Yeah, this is a really interesting thing.
Speaker 5: What is at the top? What is at the top
Speaker 5: of the rails mountain?
Speaker 3: So I would say it's not a rails mountain, it's
Speaker 3: a cycle of not a cycle, but well, let's say
Speaker 3: life cycle of every rails developer. So it's also another
Speaker 3: model I developed for another talk in Ukraine, and I
Speaker 3: simply spotted that many of Ruby developers go through the
Speaker 3: same steps and I was on many of them as well.
Speaker 3: So the first step when you love rails, when you
Speaker 3: believe in Rail's way and you just fell in love.
Speaker 3: Then later on you started getting some problems and you
Speaker 3: fix them with some magic, and after like several attempts
Speaker 3: to fix stuff with magic, you might get disappointed in
Speaker 3: rails way. And then you switch to another step where
Speaker 3: you start learning about all the alternative approaches like solid dryer,
Speaker 3: be I don't know, trail blazer service objects and so
Speaker 3: on of course patterns. Then you can, of course find
Speaker 3: your spot where you feel comfortable because like your projects
Speaker 3: of a specific size, or like you just found your
Speaker 3: way of managing complexity in web publications. But many people
Speaker 3: they decided that all right, something is wrong with the Ruby,
Speaker 3: something might be wrong with the way we develop applications,
Speaker 3: and they started to leave and they decided they should
Speaker 3: try other languages, other approaches. And this is step three
Speaker 3: and step four, like the final the top of the
Speaker 3: mountain is when you managed to learn from all those
Speaker 3: approaches in different ecosystems and.
Speaker 2: You well on the top level.
Speaker 3: It actually doesn't matter for you what technology you use,
Speaker 3: but you can return to Ruby, and you can return
Speaker 3: to Rails with all this knowledge, and you've broken the metrics,
Speaker 3: so now you know how to do stuff.
Speaker 2: So that's the final step.
Speaker 1: Yeah, I think for me getting up to that matrix's
Speaker 1: broken place, it originally came from me learning Rails before
Speaker 1: I learned Ruby. That was probably one of the biggest
Speaker 1: mistakes that I made. I just dove right into Rails
Speaker 1: without understanding how Ruby classes worked, how to create true,
Speaker 1: plain old Ruby objects, and so I would have super
Speaker 1: fat controllers with super fat models. Things were not maintainable,
Speaker 1: they were not manageable. I had zero unit tests on
Speaker 1: my old applications, and I thought that man rails isn't
Speaker 1: really all that intuitive, it's not all that great. So
Speaker 1: it really was, hey, maybe I'm just a bad programmer,
Speaker 1: which is kind of down in your Rails disciple way.
Speaker 1: So for me, it was getting up to that peak
Speaker 1: of the mountain by actually learning Ruby, picking up on
Speaker 1: some Ruby techniques like minimalization, or just creating Ruby objects
Speaker 1: instead of just relying what just rails provides. So becoming
Speaker 1: a better Ruby developer made me understand a lot more
Speaker 1: and become a better Else developer.
Speaker 6: Essentially.
Speaker 5: Do you think that people hit that stage faster with
Speaker 5: Ruby and rails because it's so good at accelerating you
Speaker 5: through the early stuff.
Speaker 1: For me, I would say no, I was a pretty
Speaker 1: horrible developer for a long time, mostly because I was
Speaker 1: just trying to do things by myself. I wasn't including
Speaker 1: other people in my work, and that inherently limited me
Speaker 1: on what I was able to do.
Speaker 4: So Von, I feel like I'm seeing a pattern here
Speaker 4: that you are taking these abstract concepts and putting them
Speaker 4: into pictures and for the most part, like you seem
Speaker 4: to be getting good reception of it. Like I myself
Speaker 4: am connecting with this kind of stuff. I feel like
Speaker 4: it's kind of analogous to you know that, maybe that
Speaker 4: one dude that you know that like maybe it makes
Speaker 4: good analogies all the time kind of thing. I feel
Speaker 4: like it's kind of like that, like that kind of
Speaker 4: a person tends to be able to Maybe it's a
Speaker 4: skill of a teacher. I don't know exactly where I'm
Speaker 4: going with this, but I feel like there's something here,
Speaker 4: which is I think what you're coming to tell us
Speaker 4: they like, Hey, maybe I don't have a system, I
Speaker 4: haven't measured it yet, but but here's the beginnings of
Speaker 4: one is that where you feel like you are in
Speaker 4: the process or do you feel like you're further along?
Speaker 2: So, yeah, I do.
Speaker 3: I do a lot of teaching, and like a lot
Speaker 3: of my relatives at teachers, so I have some something
Speaker 3: something like this, and yeah, these things I'm talking about
Speaker 3: here and there, they are kind of a part of
Speaker 3: a bigger system that I have.
Speaker 2: In my mind.
Speaker 3: And also I've tried to write a book. It should
Speaker 3: called Painless Rails. But yeah, it's already two years after
Speaker 3: I started writing it and right now it's in postponed state.
Speaker 3: But like the bigger the big goal for me is
Speaker 3: to make development using rails joyful again. Because I'm a freelancer,
Speaker 3: I usually I frequently switched from project to project, and
Speaker 3: I see that a lot of people they inventing their
Speaker 3: own bicycles. I mean, remember those times when we had
Speaker 3: like single rails, way, when we were all on the
Speaker 3: step one of this mountain. We all were enjoying the process.
Speaker 3: And then we started like inventing more approaches because like
Speaker 3: we all grew, our projects become bigger and more complex.
Speaker 3: We needed some other methods to manage complexity. But we
Speaker 3: ended up having like dozens of different approaches and there's
Speaker 3: no single unified way of doing that. Now, I think
Speaker 3: ideally we should have one unified approach again would feed
Speaker 3: to ninety percent of all projects. Of course, like the
Speaker 3: domain models and a lot of specifics is different. But
Speaker 3: I'm still pretty sure that for ninety percent of ninety
Speaker 3: percent of a project, for ninety percent of functionality of
Speaker 3: ninety percent of all rails projects or web projects on Ruby,
Speaker 3: we can develop a single unified way. Like imagine if
Speaker 3: we could measure mathematically like a different a progress like
Speaker 3: with Trailblaser, we have a complex situatio of I don't
Speaker 3: know five, and some another metric of I don't know ten,
Speaker 3: and for another like wul rails approach, we.
Speaker 2: Have like those numbers of.
Speaker 3: Seven and six, and we could just compare those approaches
Speaker 3: and let's say and this this approach is optimal. And
Speaker 3: while it sounds pretty like fantastic, I would say I
Speaker 3: still think it's doable.
Speaker 2: Man, I can explain it, but it's gonna take some time.
Speaker 4: So from my perspective, I think that that right there,
Speaker 4: that motivation to sort of like get the I don't
Speaker 4: know that there's I look at this as sort of
Speaker 4: being a platonic thing that there's there's a perfect thing
Speaker 4: out there and we're all trying to go get it, right,
Speaker 4: We're all trying to seek it. And I feel like
Speaker 4: that is sort of like the motivation that drives like
Speaker 4: half of the things that you see out in the world.
Speaker 4: You know, somebody's upset about rails, you know. Now we
Speaker 4: have what Sinatra Anami. I mean, they're even on your mountain, right,
Speaker 4: like they're so popular. Trailblazer is not exactly competitor rails
Speaker 4: so much, but it's it's competing against like pieces of it.
Speaker 6: Right.
Speaker 4: But like we have these things where somebody's like I'm
Speaker 4: going to try and seek that one thing, right or
Speaker 4: you know, in JavaScript world, we have this like we
Speaker 4: have React, now we have you. Somebody's gonna come up
Speaker 4: with another, you know framework. I mean Angular is kind
Speaker 4: of like sort of underway, and Ember is basically kind
Speaker 4: of gone.
Speaker 6: You know, we're not even talking about.
Speaker 4: The generation before that, right, Like that are just gone now,
Speaker 4: Like people are always like trying to recreate this bicycle
Speaker 4: to achieve that one place. I don't know that we
Speaker 4: can stop that cycle.
Speaker 5: I think there's always going to be more churn in
Speaker 5: the front end than the back end.
Speaker 4: That wasn't my conclusion, but you're welcome to make that conclusion.
Speaker 3: So let me explain what I mean sure, and why
Speaker 3: I think it's achievable, well at least theoretically. So, first
Speaker 3: of all, this approach of expressing code in.
Speaker 2: Pictures of little dudes.
Speaker 3: So what ways to analyze our code we have right now?
Speaker 3: So we have code coverage, for example, we have some
Speaker 3: complexity metrics with flog or some other stuff with.
Speaker 2: Rugby Critick, but those are numbers.
Speaker 3: And let's say you have a class of five hundred
Speaker 3: lines of code, and alright, you have a metric that
Speaker 3: your class has complexity of something like I don't know, fifteen,
Speaker 3: and that doesn't give you like a lot of information
Speaker 3: you can work with.
Speaker 2: And most of.
Speaker 3: The tools give us very low level hints on code quality.
Speaker 2: And we tend to think that rubocop hints are.
Speaker 3: About code quality, but I think those are just about
Speaker 3: code style mostly, and they can't show you that something
Speaker 3: is wrong, but they can't give you a high level hints.
Speaker 2: And now let's say we take the same.
Speaker 3: Class of five hundred lines and when we try to
Speaker 3: express it with the picture of little dudes, we can
Speaker 3: have like here's old guy and this guy.
Speaker 2: So since all.
Speaker 3: The arms are methods, let's say we have seven methods.
Speaker 3: So our guy has seven arms, and we see like this,
Speaker 3: and yeah, in my talk, I was showing like the
Speaker 3: if the method is to loan, then the army is
Speaker 3: kind of lone and wavy. And from that picture you
Speaker 3: already see that it's not very good to have such
Speaker 3: an army.
Speaker 2: It's not very convenient.
Speaker 3: And for another method you have you have seven arguments there,
Speaker 3: and seven arguments are seven fingers, and the army with
Speaker 3: seven fingers is not convenient also, and so on and
Speaker 3: so on and so on like and now you have
Speaker 3: this class and the properties of the code expressing in
Speaker 3: one little compact picture, and your brain is actually, well,
Speaker 3: it works with visual objects much better when with the text,
Speaker 3: and it takes you less time to understand.
Speaker 2: Property of this picture.
Speaker 3: And actually, there is a thing called channal faces, and
Speaker 3: it's used.
Speaker 2: You can google for it.
Speaker 3: And this is a technique when people used faces with
Speaker 3: different expressions to show multi dimensional data. For example, you
Speaker 3: have a table with a lot of columns and you
Speaker 3: have to.
Speaker 2: Like, I don't know, it's.
Speaker 3: Something like it's showing some death rates or some information
Speaker 3: about health in different states. And for example, death rate
Speaker 3: is expressed with the size of eyes and like and
Speaker 3: I don't know, something else is expressed with the size
Speaker 3: of mouth and so on and so on. So and
Speaker 3: this uses parts of our brain which recognize faces. And
Speaker 3: with this you can get very efficient. And this I
Speaker 3: found very close, this channal faces thing. And yeah, and
Speaker 3: what I found that if you use this in dynamics.
Speaker 3: So let's say we we have this picture of a
Speaker 3: five one hundred lines class and then we get a
Speaker 3: pull request which changes this class and maybe some others.
Speaker 3: Then we can have another picture. Then this arm is gone,
Speaker 3: this arm got two new fingers, and this arm.
Speaker 2: Become longer, and so on and so on.
Speaker 3: So now you can, like very compactly you can see
Speaker 3: what differences, what high high level differences were added to
Speaker 3: your system.
Speaker 5: So this is so that would be kind of part
Speaker 5: of some kind of continuous integration system.
Speaker 3: Yes, correct, Actually, so two links I've sent to you,
Speaker 3: the one which called dudes up. This is a prototype
Speaker 3: which is developed by my student.
Speaker 2: Which already does that.
Speaker 3: Actually, so you can plug it to your pository and
Speaker 3: it will start posting you pictures of those little dudes.
Speaker 2: Whenever you create full request?
Speaker 4: Does it work on Ruby? It looks like as a
Speaker 4: gem f on a cat file.
Speaker 3: Yeah, it should work. I Unfortunately I didn't have the
Speaker 3: chance to play with it a lot. And as I said,
Speaker 3: it's a prototype, but it should work.
Speaker 4: Okay, awesome, let's see here. I'm not sure it looks
Speaker 4: like an app. All right, well we'll link it in
Speaker 4: the stuff or whatever you play with.
Speaker 3: Oh yeah, so the gem is the last one called
Speaker 3: Judity and Dude's tap is. Yeah, it's an app. Basically
Speaker 3: it should be deployed first to Yeah, but I think
Speaker 3: I should just do that so that you could be
Speaker 3: able to plug it to your report.
Speaker 6: Should they work together or something?
Speaker 3: Is a gem that you can pluck to your repository.
Speaker 3: And I believe it's a common line utility and you
Speaker 3: can say, well, please express these classes as those pictures
Speaker 3: of little nets and you will get that.
Speaker 6: Gotcha?
Speaker 3: Do gl is the Yeah, it's a librariation of it. Yeah,
Speaker 3: it's the core of the whole thing which actually draws
Speaker 3: all those Uh. This can potentially change a way of
Speaker 3: thinking about code complexity, and of course it requires a
Speaker 3: lot of more research, and I don't know marketing, sure,
Speaker 3: but yeah, I like it.
Speaker 4: So it sounds like what you're arguing here, Please correct
Speaker 4: me if I'm wrong. Sounds like what you're kind of
Speaker 4: making an argument for is that if you express your
Speaker 4: code quality in this visual kind of language, you basically
Speaker 4: can do I think two things. One you're cutting down
Speaker 4: on noise, and two you're increasing bandwidth because we're using
Speaker 4: more parts of our brain to help kind of handle
Speaker 4: this or whatever, So you're communicating with more bandwidth.
Speaker 3: Correct, Yes, I mean the amount of information you can
Speaker 3: express in one place is also important. Like remember that
Speaker 3: our brain can handle only like seven five to seven
Speaker 3: things in one bite like here.
Speaker 2: Because of the compactness, you.
Speaker 3: Can place like a decent amount of colde and analyze
Speaker 3: it in one place on one picture.
Speaker 1: Yeah, And I think that where I like this is
Speaker 1: the at a glance visual of where things are at.
Speaker 1: So if I guess one of these little people or
Speaker 1: dudes as looks like they're called, if one of them
Speaker 1: has ten different norms, that would essentially be like ten
Speaker 1: different public methods that that class has, which in a
Speaker 1: lot of cases, if you're creating a poro, would not
Speaker 1: be ideal. So right off the bat, you could say, wow,
Speaker 1: this class has some serious complexity because you have ten
Speaker 1: different entry points to be able to interact with this class.
Speaker 1: Maybe we should simplify it so it only has one
Speaker 1: arm at most two and then create other smaller classes
Speaker 1: to handle whatever the other methods public methods were that
Speaker 1: this class was originally housing.
Speaker 2: Correct. Yes, that's a good example.
Speaker 3: I did similar thing in my talk in a trubconf
Speaker 3: I just took another talk of Sandy Mats where she
Speaker 3: was doing exactly that.
Speaker 2: She took one huge class and step by step.
Speaker 3: She splitted it into something like fifteen smaller classes, and
Speaker 3: I basically illustrated the whole thing.
Speaker 2: So and yeah, you can see it in the talk itself.
Speaker 4: I mean kudos to Sandy Metz for like kind of
Speaker 4: basically doing this for so long and giving good talks
Speaker 4: right on it. But yeah, I definitely am am coming
Speaker 4: around to the thing here that having a visual would
Speaker 4: make communicating about that stuff a lot faster, because I
Speaker 4: think one of the things that I've definitely encountered is
Speaker 4: that while I've spent a lot of time looking at
Speaker 4: talks like Katrina Owen is also really good at this right,
Speaker 4: But like watching talks and reading about stuff, and I
Speaker 4: feel like I'm pretty good at identifying these things, you know,
Speaker 4: and I'll comment on them and prs and things like this.
Speaker 4: I feel like it's a very hard thing, even for programmers,
Speaker 4: who you know, we were like, oh, programmers are smarter
Speaker 4: than the average bear, and therefore they should be able
Speaker 4: to get this stuff. But I think it's a hard
Speaker 4: concept for everyone. Maybe visual language would help overcome some
Speaker 4: of those barriers.
Speaker 1: I know for me it definitely would. And just take
Speaker 1: the example this kind of like off topic but related,
Speaker 1: but like a con bond board, a combine board usually
Speaker 1: has three columns to do, doing and done. And that's
Speaker 1: great for single flow tasks, tasks that don't require anything
Speaker 1: other than a to do doing or done.
Speaker 5: The most important column which is that won't do column.
Speaker 1: A yeah yeah if yeah. But anyways, my problem with
Speaker 1: that kind of style is that you don't have a
Speaker 1: great visualization. Okay, so this story that we have now
Speaker 1: developed this feature on, it's done? What is done even mean?
Speaker 1: Does it mean that it has gone through the proper
Speaker 1: code reviews, that it has passed a QA checkpoint, that
Speaker 1: it's been deployed? You know what what does that actually mean?
Speaker 1: So in a CIACD kind of world where or a
Speaker 1: more proper development life cycle world, you have many more
Speaker 1: steps than just to do doing and done, And so
Speaker 1: I like my board's actually more visual where you do
Speaker 1: have several different columns, each column representing the next step
Speaker 1: for that story. So you're able to then see at
Speaker 1: a glance, Okay, all of my work is done. There's
Speaker 1: no more expectations for me this sprint. Why don't I
Speaker 1: pull something else in or learn something or do something else.
Speaker 1: So that way there is no confusion of oh, the
Speaker 1: story is done, but it's still actually waiting for a
Speaker 1: code review and waiting to get deployed to our staging
Speaker 1: environment something like that. So I see the visual aspect
Speaker 1: that we're talking about here with the little dudes being
Speaker 1: very helpful in not only as a for new developers
Speaker 1: but for season developers to see at a glance, what
Speaker 1: is the current situation where things currently at, How healthy
Speaker 1: is our actual code, What's what's the status of our
Speaker 1: actual stories? Just that at a simple glance view, having
Speaker 1: knowledgeable and actionable information.
Speaker 3: Yeah, I think it can be also useful if you
Speaker 3: want to pass the knowledge about some system you're developing,
Speaker 3: and like especially of some part of some of some
Speaker 3: tricky part of the system. Definitely you can draw it
Speaker 3: in this way and then first of all, you're sharing
Speaker 3: this picture and then you explain what it means, like
Speaker 3: and yeah, and this way you can get like a
Speaker 3: more compact way to to to explain things. And I
Speaker 3: guess you can hope that people will understand it's more correct.
Speaker 3: I hope that it will work it this way.
Speaker 6: I think.
Speaker 4: So I definitely am really into this image thing. I
Speaker 4: think I also agree with you, Dave right.
Speaker 6: I agree.
Speaker 4: I have a small critique, but I mostly agree about
Speaker 4: the combon board thing, as I say, because my combin board,
Speaker 4: I think everyone has a common board that like you
Speaker 4: make a trade off decision between having enough columns to
Speaker 4: actually capture all the states that you care about, you know,
Speaker 4: because my combon board is like seven columns big, because
Speaker 4: you know, I'm focused on.
Speaker 2: Well, how did you get the seven?
Speaker 6: All right?
Speaker 4: So I have the like the needs grooming column right,
Speaker 4: the actual backlog, you know, Then you have in progress.
Speaker 4: Then I have an in review column, which means that hey,
Speaker 4: somebody else is supposed to like look at this thing
Speaker 4: and do you know, do something, and then there's a
Speaker 4: ready to deploy column, and then there's it completed, and
Speaker 4: then of course the ice box, right, because you can't
Speaker 4: forget the icebox or seven. Okay, well that visually I
Speaker 4: have a large screen here, and that visually takes up
Speaker 4: the whole screen if I'm on my laptop screen.
Speaker 6: I think the seventh column is hidden. You know, it's not.
Speaker 5: Good screen can board.
Speaker 4: Right, But anyway, so I'm not trying to get too
Speaker 4: down and nuts, but my point is there is visual
Speaker 4: information being drawn from this, but I think it's a
Speaker 4: stretched prop like this is a problem where the illustration
Speaker 4: is stretched too far right, And I think that what
Speaker 4: is making me really comfortable about this code thing is,
Speaker 4: at least so far, I can't think of a way
Speaker 4: right in which this gets stretched, like I think, Yvon,
Speaker 4: like you've captured basically most of the problems I can
Speaker 4: think of.
Speaker 6: So we're just talking.
Speaker 4: About a high bandwidth communication solution for something that's a
Speaker 4: problem right now.
Speaker 6: It's just an easy cell, I think.
Speaker 5: Yeah, I mean the potential is enormous. Ivan. I really
Speaker 5: liked your bit in your talk when you talked about
Speaker 5: the exceptions and how you visualize exceptions as a vomit.
Speaker 3: Yeah, basically things go wrong, and you should understand me
Speaker 3: that most of the things I haven't tried to it
Speaker 3: was not hard. Like they really drive you when once
Speaker 3: you get these basical laws of your universe, like you
Speaker 3: basically think, all right, and how this thing will look like,
Speaker 3: and like, yeah, it's it's it's obvious.
Speaker 5: Not like something woman that was really evocative. And what
Speaker 5: it immediately occurs to me is some kind of monitoring
Speaker 5: system combined the concept of the regurgitating exceptions with the dudes,
Speaker 5: and you can assign the regurgitations to the dudes so
Speaker 5: you can see which classes are being physically sick.
Speaker 6: I did just look through the repo.
Speaker 4: There's nothing about failing tests like and the guy throwing up.
Speaker 6: It's not implemented yet.
Speaker 5: But that's my weekend gun.
Speaker 1: In some ways, this reminds me a gym that I
Speaker 1: played around with a while ago, several years ago, rails erd.
Speaker 1: But this has a much better at a glance visualization
Speaker 1: of communicating data and state of your rail's application. So
Speaker 1: I think it's really cool. I may check this out
Speaker 1: a bit further.
Speaker 5: I do have some problems with it. Ivan wonder. The
Speaker 5: things that struck me as odd was the methods with
Speaker 5: too many lines of code in them were depicted as
Speaker 5: swollen arms. So the methods of the arms already and
Speaker 5: when they have too many things in them they become swollen.
Speaker 2: Correct, not exactly like this.
Speaker 3: So if the method is long, then you have a
Speaker 3: long wavy arm. Your arm gets swollen if there is
Speaker 3: too many conditional logic in it.
Speaker 2: So it means like you get it right.
Speaker 5: It's a complexity score.
Speaker 3: It's kind of so because so basically this here it's
Speaker 3: used to demonstrate the nature of complexity. This is what
Speaker 3: I came to. So I think with this, with this approach,
Speaker 3: you can show that there are two types of complexity.
Speaker 3: One of one is internal where you have like swollen arms,
Speaker 3: long arms and too many methods and too many internal methods.
Speaker 2: This is all internal complexity.
Speaker 3: And external complexity is where you have small.
Speaker 2: Classes but you have tons of them.
Speaker 3: So basically, the point I was making in the end
Speaker 3: of my talk after I illustrated send them stock is
Speaker 3: that complexity actually.
Speaker 2: Didn't go away, it just changed the form.
Speaker 3: So and so it was all internal complexity. It was
Speaker 3: all in one single class. And now we have fifteen
Speaker 3: classes and the complexity is now external. So we managed
Speaker 3: complexity in this way. But sometimes you can have a
Speaker 3: lot of classes, but it's still hard to deal with
Speaker 3: those classes, so it means you've gone too far with
Speaker 3: your OPO, like basically designed. So that's the idea, And
Speaker 3: I think that when we are saying that we want
Speaker 3: to write in like the good code, the whole question
Speaker 3: is about the balance between internal complexity and external complexity.
Speaker 3: So sometimes it's okay to have like conditions. Sometimes you
Speaker 3: have to split it into polymorphic classes, but that's up
Speaker 3: to you to decide.
Speaker 4: Yeah, I think I think that's kind of what I
Speaker 4: was hinting at a little bit earlier, right, Like, I
Speaker 4: think it's very difficult for people to actually recognize and
Speaker 4: know where they've put their complexity. Right, people are really
Speaker 4: quick to recognize, you know, fat controllers and fat models,
Speaker 4: but like, underneath the hood, the reason why fat controllers
Speaker 4: for fat models bother us is because of you know, Okay,
Speaker 4: I have a ton of conditionals in all of my methods,
Speaker 4: or I have a million lines in every method right
Speaker 4: I'm basically writing imperative code inside my op box here,
Speaker 4: And uh, maybe there's a different Maybe there's a different
Speaker 4: way to put that right, Like maybe this method is
Speaker 4: super hard to test or something, right, Like, there's a
Speaker 4: lot of reasons why you might want to move it out.
Speaker 4: And typically I feel like we're like, look, if we
Speaker 4: can write easy tests, then this is pretty good code
Speaker 4: and I can maintain it or whatever, And that's sort
Speaker 4: of like our way to measure that our complexity isn't
Speaker 4: out of sorts. But yeah, I think the reason why
Speaker 4: this tool is awesome the way that I'm understanding from you, Yvon,
Speaker 4: is it's awesome because it makes it really quick to
Speaker 4: be able to communicate to somebody else. This is where
Speaker 4: all the this is, this is how all the pieces lie, right, Like, Okay,
Speaker 4: there's a bunch of skinning skinny long arms, or there's
Speaker 4: a bunch of fat long arms, or there's just fat
Speaker 4: arms or whatever. Like I suddenly I am giving you
Speaker 4: a ton of information about where you chose to put
Speaker 4: your complexity exactly right.
Speaker 3: And when I'm talking about the optimal way of developing
Speaker 3: application using some approach like let's say rails, I'm actually
Speaker 3: it's talking about this so we can quantify the way
Speaker 3: we work, Like let's say, if we.
Speaker 2: Like every requirement we get from the customer.
Speaker 3: We we can quantify in a way like here we
Speaker 3: should add a new entity like here we we have
Speaker 3: a fork in business logic. Here we have something else
Speaker 3: and something else and something else. And let's say we
Speaker 3: we we've done that. And also we can with this
Speaker 3: visual approach, we can quantify different approaches like Trailblazer approach,
Speaker 3: like dryer be approach, Hanani and rails and I don't know,
Speaker 3: rails plus service objects. For every specific approach, you can
Speaker 3: say that, all right, in rails, I just threw another
Speaker 3: condition in my controller and I'll be fine, and you
Speaker 3: can visually see that, all right, this arm got got
Speaker 3: bigger or got more fat fatter. With another approach, with Hanani,
Speaker 3: I've added one repository, one service, one class for my action.
Speaker 3: And I see that I've added another kind of complexity.
Speaker 3: I've added three more classes. And this way you can compare,
Speaker 3: so you can see that here we added internal complexity.
Speaker 3: Here we are added external complexity. And now with this
Speaker 3: approach we can measure for every typical feature we're developing.
Speaker 3: Of course we can, we can, we should really simplify this,
Speaker 3: but for theoretical ways, it should be enough. So for
Speaker 3: this way, we get this amount of internal complexity, this
Speaker 3: amount of external complexity, and we can now compare those numbers.
Speaker 3: So whatever those numbers are, and if we can compare
Speaker 3: those numbers, we potentially we can find this balance. We
Speaker 3: could find that optimal approach which would add an optimal
Speaker 3: amount of internal complexity and optimal amount of external complexity.
Speaker 3: This is what I was talking about actually when I
Speaker 3: was saying that, I think that it is still possible
Speaker 3: to find an optimal way of managing complexity in Reil
Speaker 3: supplications or whatever, web applications, in written and ruby, well
Speaker 3: actually in any language, because it's nothing limits its usage
Speaker 3: to the language itself.
Speaker 4: Sure, I mean we put a value too, like a
Speaker 4: dude versus a fat arm, for example. Once we have
Speaker 4: those values, then we should be able to compare them.
Speaker 6: Right. Is that's what we're getting at here?
Speaker 2: Right?
Speaker 3: Yeah? You basically visualize all the trade offs you're doing,
Speaker 3: so we you're changing this thing for that thing.
Speaker 2: This is what you get.
Speaker 5: It's a fascinating idea. I still think the the complex methods.
Speaker 5: If the arms are big, people might like that because
Speaker 5: they like to have big arms. So they think that
Speaker 5: these aren't swollen methods, they're kind of muscular methods.
Speaker 3: Well, if you add a few most segments to the term,
Speaker 3: you don't like it, you don't, you will not like
Speaker 3: that much.
Speaker 4: Yeah, go look at uh go get look at the
Speaker 4: images on digity or whatever. They look a lot less
Speaker 4: like swollen arms and they look more like I don't know,
Speaker 4: resistors or like like those images those diagrams of in
Speaker 4: like biology class of like the I don't know, the
Speaker 4: sheets wrapping around your nerves or whatever whatever that's called.
Speaker 6: It don't look like small arms. Yeah.
Speaker 2: Of course, as I said, it's a prototype. It's a
Speaker 2: very simplistic pictures.
Speaker 3: But yeah, they're still able to express the initial Leadzier.
Speaker 4: I think, oh yeah, yeah, no, No, that's what I'm
Speaker 4: not critiquing. I'm saying that I don't think you have
Speaker 4: to worry about people confusing them for small arms.
Speaker 6: I think we're good.
Speaker 2: Yeah.
Speaker 4: I think I'm gonna add this to a project legit,
Speaker 4: because I mean, I have a project dot there right
Speaker 4: now that I'm kind of working on, and you know,
Speaker 4: I'm running Rubacopriek and Rail's Best Practices on it, and
Speaker 4: you know, I mean, it's a pain in the butt
Speaker 4: to test. All three probably need to doc rize the
Speaker 4: dude's hub saying, but yeah, I bet we could.
Speaker 6: I bet you could do this.
Speaker 2: Yeah, that would be great. Yeah, and please give me
Speaker 2: some feedback.
Speaker 1: Cool. If if people want to follow you and see
Speaker 1: what you're doing online, where should they go?
Speaker 2: So on Twitter? I I am, I an E m IM.
Speaker 3: I guess and yeah, I think it's it's a good point.
Speaker 3: If you want to see other stuff I was working
Speaker 3: on at im dot as so you can see some
Speaker 3: other projects of mine, And yeah, that's it's probably of
Speaker 3: course my tungus bro I was working on as well.
Speaker 1: Awesome. Let's go ahead and move on to some picks. Luke,
Speaker 1: do you want to start us off?
Speaker 5: My pick, because I've been doing it all week, is Linode,
Speaker 5: the hosting company. I've been watching some of their videos
Speaker 5: from last year, which was I think their nineteenth anniversary,
Speaker 5: and the founder was pointing out that Linode is an
Speaker 5: older company than Amazon Web Services for cloud hosting, so
Speaker 5: check them out linodelinode dot com.
Speaker 1: Awesome, And John, do you have any I do?
Speaker 4: My first one is it's sort of a mixed PSA
Speaker 4: slash you know, Rediscovery whatever. Back when I was like
Speaker 4: super poor in college, you know, and working out was
Speaker 4: like too expensive. You know, I did push ups and
Speaker 4: sit ups like all the time. That was the same
Speaker 4: that I did. And you know, now that you have
Speaker 4: to be at home, you know, just like reminded.
Speaker 6: I've been doing my push ups and sit ups again.
Speaker 4: I've actually been doing it for a few months, but
Speaker 4: but I'm just like reminded of how awesome a choice
Speaker 4: that is. Since I don't I can't go out to
Speaker 4: work out anywhere else. So so yep, that was pick
Speaker 4: number one.
Speaker 5: I've got to ask how many push ups can you do?
Speaker 4: How many can I do? Or how many do I
Speaker 4: do every day? Because those are completely different numbers.
Speaker 5: Well, I want to note both the numbers.
Speaker 4: Okay, well I can do about fifty or sixty and
Speaker 4: one go, which is I don't know, it's okay, God.
Speaker 5: You're going to end up looking like one of the
Speaker 5: Ivans Method people.
Speaker 4: I feel like if I look like one of Ivan's
Speaker 4: method people would be harder for me to do those
Speaker 4: push ups and sit ups.
Speaker 6: But no, I I do.
Speaker 4: I do twenty in two sets every day. So because
Speaker 4: you don't want to go to your limit whatever anyway
Speaker 4: I should. I should be jumping it up to twenty
Speaker 4: five soon, I think, and I'm not feeling it yet. Okay,
Speaker 4: So the second thing that I was trying to but
Speaker 4: my second pick is so I have an acre and
Speaker 4: a quarter and I'm backed up to some woods and
Speaker 4: the whole area around me is very woody and stuff.
Speaker 4: So I have lots of brush things that are hard
Speaker 4: to mow around. I live on a hill, you know,
Speaker 4: so like I can't. I can't mow that hill, at
Speaker 4: least not on a riding lawn mower. So I do
Speaker 4: I have, you know, a pretty heavy duty weed whacker,
Speaker 4: you know, and I've just like, you know, I don't know,
Speaker 4: I bought the thickest string that it could handle whatever. Cool, great,
Speaker 4: but it's just what I don't know. It just broke
Speaker 4: all the time and everything. So anyway, the thing that
Speaker 4: I'm picking is like I bought a head to replace
Speaker 4: it so that I could not only use sticker string,
Speaker 4: but that like I bought a head that I cut
Speaker 4: off these eight inch strings and just like stick them
Speaker 4: in instead of having like a reel that bumps and
Speaker 4: then like I don't know, stops working for whatever reason. Anyway,
Speaker 4: I've been super happy with the fact that I like
Speaker 4: replaced my head. So I'm not saying you should do
Speaker 4: exactly what I did, but I like looked up online
Speaker 4: how this stuff worked, and I came away, bought ahead,
Speaker 4: replaced it on my weed whacker, and now instead of
Speaker 4: taking two and a half hours, it takes two Still
Speaker 4: a lot of time shaved about a half hour, but like,
Speaker 4: that's a half hour of like me being pissed because
Speaker 4: my string broke, so it's totally worth it. Yeah, it's
Speaker 4: just been a better experience. So yeah, I don't know,
Speaker 4: find the weed whacker head that works for you.
Speaker 6: That's my pick.
Speaker 1: Cool and avone, Do you have any picks?
Speaker 2: Nope, I actually didn't prepare anything. Well.
Speaker 3: I would say if you never tried, try using If
Speaker 3: you're into vs code, try using viscode remote.
Speaker 2: I switched to.
Speaker 3: This way of working like several months ago, so whenever
Speaker 3: I start new projects, I no longer set it up
Speaker 3: on my local machine. I simply spin up another virtual
Speaker 3: server on clean Ote, on Scaleways on Amazon and set
Speaker 3: my stuff, set up my stuff there and simply work
Speaker 3: using Visco Remote work. As it's in my log as
Speaker 3: it is on my local machine, so if you never
Speaker 3: tried that, I highly recommend.
Speaker 1: It cool and I'll jump in with a few picks.
Speaker 1: So the first pick is the discount code learn from
Speaker 1: Home on a site that I run, Drifting Ruby, which
Speaker 1: is a series of screen cast believe I'm up to
Speaker 1: over two hundred and thirty now, so learn from Home.
Speaker 1: And a second pick as far as just talking about
Speaker 1: code quality and stuff, is a pretty cool gym called reek,
Speaker 1: which will give you a nice kind of more of
Speaker 1: a table visualization similar to what simple cub does of
Speaker 1: all the different code complexity issues that you might have
Speaker 1: within your application. And a third pick, which is kind
Speaker 1: of more of an anti pick. It's a love hate
Speaker 1: thing is I've been really diving a lot more into
Speaker 1: Kubernetes lately and it's a lot of fun. I've been
Speaker 1: having some enjoyment doing it and then also a lot
Speaker 1: of frustration. So that's kind of a pick anti pick.
Speaker 4: So have another episode on that stuff so that you
Speaker 4: can talk about how your views have evolved or not evolved.
Speaker 1: Well, so I will say I am working on a
Speaker 1: pretty cool templating thing that I'm going to start all
Speaker 1: my new applications, not the ones that I do for dritchery,
Speaker 1: because I'll like Kumudo slim, but any application that I
Speaker 1: do personally, it's going to have the doctor composed and
Speaker 1: doctor file built into the new rails app. It's going
Speaker 1: to then also generate all of the YAMO files for
Speaker 1: deploying that application over to a Kubernetes cluster that has
Speaker 1: an ingress enabled, so all you have to do is
Speaker 1: deploy it and they'll create a whole new environment. So
Speaker 1: I've been playing a round with that quite a bit lately.
Speaker 6: Cool. But also i'd give a thumbs up for Riek two.
Speaker 6: I do use it, and I do love it. Right.
Speaker 4: I just having multiple code quality checks in one tool,
Speaker 4: and I also don't want to go out there and
Speaker 4: pay for one to either.
Speaker 1: And I think there's another one called standard RB something
Speaker 1: like that, which will actually do all of the linking
Speaker 1: changes for you, and it's a pretty safe one. I
Speaker 1: think test double mates. It can't remember, it's been a
Speaker 1: while since I've seen it.
Speaker 6: Yeah, I vaguely recall it. I'm just checking out it
Speaker 6: is standard IV that is the same yep.
Speaker 5: Cool?
Speaker 1: All right, well, Ivine, I appreciate you coming on and
Speaker 1: talking with us, and that's a wrap.
Speaker 2: Thank you guys, thanks swimming lights and me.
Speaker 6: Thanks for coming.
Speaker 2: Yeah.
Speaker 5: Thanks, that was really really interesting.