January 8, 2025 • 46 mins
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.
Links
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Links
- Chernoff Faces
- dmikhr/DudeGL - "Anthropomorphic UML": visualization of code and OOP concepts in a form of human body.
- dmikhr/Dudity - Analyze Rails code with stick dudes
- dmikhr/DudesHub - Visualize code diffs in GitHub
Picks
- Dave - Drifting Ruby - Discount Code - learnfromhome
- Dave - troessner/reek: Code smell detector for Ruby
- Dave - Kubernetes
- John - Pushups and Situps at home instead of working out
- John - Get a new Weed Whacker head
- Luke - Linode
- Ivan - Follow Ivan on Twitter > @inem, Github, Website
- Ivan - Visual Studio Code Remote Development
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
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.
Speaker 2 (00:20):
Hi. Guys, thanks poin inviting.
Speaker 1 (00:22):
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.
Speaker 3 (00:29):
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,
(00:51):
and all the different stuff.
Speaker 1 (00:53):
Awesome. So what have you been up to lately?
Speaker 3 (00:57):
Just some freelance and some consulting. Also is amount of teaching,
of course.
Speaker 1 (01:01):
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.
Speaker 3 (01:15):
Yeah, in a visual way, uh, in pictures in pictures, right?
Speaker 2 (01:21):
Would you mind.
Speaker 1 (01:21):
Giving us a highlight overview of that talk?
Speaker 2 (01:24):
Sure?
Speaker 3 (01:25):
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
(01:48):
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.
Speaker 2 (02:02):
The correct way.
Speaker 3 (02:04):
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
(02:28):
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.
Speaker 2 (02:49):
And then and more and more and more, and.
Speaker 3 (02:54):
I managed to develop some kind of visual language to
express ask what's going on in your code.
Speaker 2 (03:03):
So yeah, something like this.
Speaker 4 (03:06):
I mean, your pictures are awesome. Did you come to
a conclusion, did you measure that this works?
Speaker 3 (03:13):
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,
(03:33):
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
(03:56):
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,
(04:21):
and and.
Speaker 2 (04:22):
So on and so on and so on.
Speaker 3 (04:23):
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.
Speaker 5 (04:40):
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?
Speaker 2 (05:00):
Yeah?
Speaker 3 (05:01):
People usually like it a lot because it's a very
surprising way of thinking about the.
Speaker 2 (05:07):
Code for them.
Speaker 3 (05:08):
So yeah, people are really excited, but I don't think
many of them find it very practical so far.
Speaker 5 (05:17):
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?
Speaker 3 (05:35):
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
(05:57):
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
(06:19):
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
(06:43):
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,
(07:03):
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
(07:24):
approaches in different ecosystems and.
Speaker 2 (07:27):
You well on the top level.
Speaker 3 (07:30):
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.
Speaker 2 (07:43):
So that's the final step.
Speaker 1 (07:45):
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,
(08:07):
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
(08:30):
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
(08:51):
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.
Speaker 6 (09:00):
Essentially.
Speaker 5 (09:02):
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.
Speaker 1 (09:14):
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.
Speaker 4 (09:32):
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
(09:54):
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
(10:15):
the process or do you feel like you're further along?
Speaker 2 (10:17):
So, yeah, I do.
Speaker 3 (10:19):
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.
Speaker 2 (10:38):
In my mind.
Speaker 3 (10:39):
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,
(11:07):
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.
(11:31):
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
(11:54):
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
(12:17):
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,
(12:42):
and for another like wul rails approach, we.
Speaker 2 (12:45):
Have like those numbers of.
Speaker 3 (12:47):
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.
Speaker 2 (13:05):
Man, I can explain it, but it's gonna take some time.
Speaker 4 (13:09):
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
(13:29):
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.
Speaker 6 (13:47):
Right.
Speaker 4 (13:48):
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.
Speaker 6 (14:06):
You know, we're not even talking about.
Speaker 4 (14:08):
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.
Speaker 5 (14:19):
I think there's always going to be more churn in
the front end than the back end.
Speaker 4 (14:25):
That wasn't my conclusion, but you're welcome to make that conclusion.
Speaker 3 (14:29):
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.
Speaker 2 (14:44):
Pictures of little dudes.
Speaker 3 (14:46):
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.
Speaker 2 (14:57):
Rugby Critick, but those are numbers.
Speaker 3 (15:01):
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.
Speaker 2 (15:19):
And most of.
Speaker 3 (15:21):
The tools give us very low level hints on code quality.
Speaker 2 (15:26):
And we tend to think that rubocop hints are.
Speaker 3 (15:30):
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.
Speaker 2 (15:42):
And now let's say we take the same.
Speaker 3 (15:46):
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.
Speaker 2 (15:56):
So since all.
Speaker 3 (15:57):
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
(16:20):
an army.
Speaker 2 (16:20):
It's not very convenient.
Speaker 3 (16:22):
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
(16:43):
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.
Speaker 2 (16:59):
Property of this picture.
Speaker 3 (17:01):
And actually, there is a thing called channal faces, and
it's used.
Speaker 2 (17:07):
You can google for it.
Speaker 3 (17:08):
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.
Speaker 2 (17:23):
Like, I don't know, it's.
Speaker 3 (17:24):
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
(17:44):
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
(18:06):
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.
Speaker 2 (18:25):
Become longer, and so on and so on.
Speaker 3 (18:28):
So now you can, like very compactly you can see
what differences, what high high level differences were added to
your system.
Speaker 5 (18:41):
So this is so that would be kind of part
of some kind of continuous integration system.
Speaker 3 (18:51):
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.
Speaker 2 (19:04):
Which already does that.
Speaker 3 (19:06):
Actually, so you can plug it to your pository and
it will start posting you pictures of those little dudes.
Speaker 2 (19:14):
Whenever you create full request?
Speaker 4 (19:16):
Does it work on Ruby? It looks like as a
gem f on a cat file.
Speaker 3 (19:20):
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.
Speaker 4 (19:28):
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.
Speaker 3 (19:37):
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.
Speaker 6 (19:57):
Should they work together or something?
Speaker 3 (20:01):
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.
Speaker 6 (20:17):
Gotcha?
Speaker 3 (20:19):
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
(20:41):
lot of more research, and I don't know marketing, sure,
but yeah, I like it.
Speaker 4 (20:47):
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
(21:09):
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.
Speaker 3 (21:19):
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.
Speaker 2 (21:35):
Because of the compactness, you.
Speaker 3 (21:37):
Can place like a decent amount of colde and analyze
it in one place on one picture.
Speaker 1 (21:42):
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
(22:03):
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.
(22:24):
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.
Speaker 2 (22:38):
Correct. Yes, that's a good example.
Speaker 3 (22:40):
I did similar thing in my talk in a trubconf
I just took another talk of Sandy Mats where she
was doing exactly that.
Speaker 2 (22:51):
She took one huge class and step by step.
Speaker 3 (22:55):
She splitted it into something like fifteen smaller classes, and
I basically illustrated the whole thing.
Speaker 2 (23:03):
So and yeah, you can see it in the talk itself.
Speaker 4 (23:08):
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
(23:29):
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,
(23:50):
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.
Speaker 1 (24:04):
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
(24:25):
other than a to do doing or done.
Speaker 5 (24:28):
The most important column which is that won't do column.
Speaker 1 (24:32):
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
(24:52):
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
(25:14):
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.
(25:36):
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
(25:58):
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.
Speaker 3 (26:17):
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
(26:39):
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.
Speaker 6 (26:55):
I think.
Speaker 4 (26:55):
So I definitely am really into this image thing. I
think I also agree with you, Dave right.
Speaker 6 (27:00):
I agree.
Speaker 4 (27:01):
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.
Speaker 2 (27:21):
Well, how did you get the seven?
Speaker 6 (27:23):
All right?
Speaker 4 (27:24):
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
(27:47):
have a large screen here, and that visually takes up
the whole screen if I'm on my laptop screen.
Speaker 6 (27:51):
I think the seventh column is hidden. You know, it's not.
Speaker 5 (27:54):
Good screen can board.
Speaker 4 (27:57):
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,
(28:18):
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.
Speaker 6 (28:27):
So we're just talking.
Speaker 4 (28:28):
About a high bandwidth communication solution for something that's a
problem right now.
Speaker 6 (28:34):
It's just an easy cell, I think.
Speaker 5 (28:36):
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.
Speaker 3 (28:52):
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,
(29:13):
and like, yeah, it's it's it's obvious.
Speaker 5 (29:16):
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,
(29:37):
and you can assign the regurgitations to the dudes so
you can see which classes are being physically sick.
Speaker 6 (29:47):
I did just look through the repo.
Speaker 4 (29:49):
There's nothing about failing tests like and the guy throwing up.
Speaker 6 (29:53):
It's not implemented yet.
Speaker 5 (29:54):
But that's my weekend gun.
Speaker 1 (29:58):
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.
Speaker 5 (30:18):
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.
Speaker 2 (30:38):
Correct, not exactly like this.
Speaker 3 (30:41):
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.
Speaker 2 (30:54):
So it means like you get it right.
Speaker 5 (30:58):
It's a complexity score.
Speaker 3 (31:00):
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,
(31:21):
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.
Speaker 2 (31:36):
This is all internal complexity.
Speaker 3 (31:38):
And external complexity is where you have small.
Speaker 2 (31:44):
Classes but you have tons of them.
Speaker 3 (31:47):
So basically, the point I was making in the end
of my talk after I illustrated send them stock is
that complexity actually.
Speaker 2 (31:56):
Didn't go away, it just changed the form.
Speaker 3 (31:59):
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
(32:20):
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.
(32:42):
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.
Speaker 4 (32:52):
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,
(33:16):
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
(33:38):
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
(34:00):
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.
Speaker 3 (34:16):
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.
Speaker 2 (34:31):
Like every requirement we get from the customer.
Speaker 3 (34:35):
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
(34:56):
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
(35:21):
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.
(35:42):
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
(36:06):
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
(36:29):
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
(36:51):
actually in any language, because it's nothing limits its usage
to the language itself.
Speaker 4 (36:58):
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.
Speaker 6 (37:07):
Right. Is that's what we're getting at here?
Speaker 2 (37:09):
Right?
Speaker 3 (37:09):
Yeah? You basically visualize all the trade offs you're doing,
so we you're changing this thing for that thing.
Speaker 2 (37:17):
This is what you get.
Speaker 5 (37:18):
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.
Speaker 3 (37:34):
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.
Speaker 4 (37:42):
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.
Speaker 6 (38:02):
It don't look like small arms. Yeah.
Speaker 2 (38:04):
Of course, as I said, it's a prototype. It's a
very simplistic pictures.
Speaker 3 (38:09):
But yeah, they're still able to express the initial Leadzier.
Speaker 4 (38:13):
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.
Speaker 6 (38:20):
I think we're good.
Speaker 2 (38:21):
Yeah.
Speaker 4 (38:22):
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.
Speaker 6 (38:41):
I bet you could do this.
Speaker 2 (38:42):
Yeah, that would be great. Yeah, and please give me
some feedback.
Speaker 1 (38:47):
Cool. If if people want to follow you and see
what you're doing online, where should they go?
Speaker 2 (38:53):
So on Twitter? I I am, I an E m IM.
Speaker 3 (38:58):
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.
Speaker 1 (39:20):
Awesome. Let's go ahead and move on to some picks. Luke,
do you want to start us off?
Speaker 5 (39:25):
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
(39:48):
check them out linodelinode dot com.
Speaker 1 (39:52):
Awesome, And John, do you have any I do?
Speaker 4 (39:55):
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
(40:17):
to be at home, you know, just like reminded.
Speaker 6 (40:19):
I've been doing my push ups and sit ups again.
Speaker 4 (40:22):
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.
Speaker 5 (40:33):
I've got to ask how many push ups can you do?
Speaker 4 (40:36):
How many can I do? Or how many do I
do every day? Because those are completely different numbers.
Speaker 5 (40:41):
Well, I want to note both the numbers.
Speaker 4 (40:43):
Okay, well I can do about fifty or sixty and
one go, which is I don't know, it's okay, God.
Speaker 5 (40:51):
You're going to end up looking like one of the
Ivans Method people.
Speaker 4 (40:54):
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.
Speaker 6 (41:02):
But no, I I do.
Speaker 4 (41:04):
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
(41:27):
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,
(41:49):
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
(42:11):
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,
(42:31):
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.
Speaker 6 (42:51):
That's my pick.
Speaker 1 (42:52):
Cool and avone, Do you have any picks?
Speaker 2 (42:56):
Nope, I actually didn't prepare anything. Well.
Speaker 3 (43:00):
I would say if you never tried, try using If
you're into vs code, try using viscode remote.
Speaker 2 (43:09):
I switched to.
Speaker 3 (43:10):
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
(43:31):
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.
Speaker 1 (43:45):
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
(44:05):
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
(44:26):
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.
Speaker 4 (44:42):
So have another episode on that stuff so that you
can talk about how your views have evolved or not evolved.
Speaker 1 (44:52):
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
(45:13):
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.
Speaker 6 (45:32):
Cool. But also i'd give a thumbs up for Riek two.
I do use it, and I do love it. Right.
Speaker 4 (45:38):
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.
Speaker 1 (45:47):
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.
Speaker 6 (46:02):
Yeah, I vaguely recall it. I'm just checking out it
is standard IV that is the same yep.
Speaker 5 (46:06):
Cool?
Speaker 1 (46:07):
All right, well, Ivine, I appreciate you coming on and
talking with us, and that's a wrap.
Speaker 2 (46:13):
Thank you guys, thanks swimming lights and me.
Speaker 6 (46:15):
Thanks for coming.
Speaker 2 (46:16):
Yeah.
Speaker 5 (46:16):
Thanks, that was really really interesting.
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.
Speaker 2 (00:20):
Hi. Guys, thanks poin inviting.
Speaker 1 (00:22):
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.
Speaker 3 (00:29):
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,
(00:51):
and all the different stuff.
Speaker 1 (00:53):
Awesome. So what have you been up to lately?
Speaker 3 (00:57):
Just some freelance and some consulting. Also is amount of teaching,
of course.
Speaker 1 (01:01):
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.
Speaker 3 (01:15):
Yeah, in a visual way, uh, in pictures in pictures, right?
Speaker 2 (01:21):
Would you mind.
Speaker 1 (01:21):
Giving us a highlight overview of that talk?
Speaker 2 (01:24):
Sure?
Speaker 3 (01:25):
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
(01:48):
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.
Speaker 2 (02:02):
The correct way.
Speaker 3 (02:04):
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
(02:28):
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.
Speaker 2 (02:49):
And then and more and more and more, and.
Speaker 3 (02:54):
I managed to develop some kind of visual language to
express ask what's going on in your code.
Speaker 2 (03:03):
So yeah, something like this.
Speaker 4 (03:06):
I mean, your pictures are awesome. Did you come to
a conclusion, did you measure that this works?
Speaker 3 (03:13):
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,
(03:33):
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
(03:56):
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,
(04:21):
and and.
Speaker 2 (04:22):
So on and so on and so on.
Speaker 3 (04:23):
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.
Speaker 5 (04:40):
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?
Speaker 2 (05:00):
Yeah?
Speaker 3 (05:01):
People usually like it a lot because it's a very
surprising way of thinking about the.
Speaker 2 (05:07):
Code for them.
Speaker 3 (05:08):
So yeah, people are really excited, but I don't think
many of them find it very practical so far.
Speaker 5 (05:17):
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?
Speaker 3 (05:35):
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
(05:57):
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
(06:19):
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
(06:43):
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,
(07:03):
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
(07:24):
approaches in different ecosystems and.
Speaker 2 (07:27):
You well on the top level.
Speaker 3 (07:30):
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.
Speaker 2 (07:43):
So that's the final step.
Speaker 1 (07:45):
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,
(08:07):
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
(08:30):
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
(08:51):
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.
Speaker 6 (09:00):
Essentially.
Speaker 5 (09:02):
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.
Speaker 1 (09:14):
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.
Speaker 4 (09:32):
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
(09:54):
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
(10:15):
the process or do you feel like you're further along?
Speaker 2 (10:17):
So, yeah, I do.
Speaker 3 (10:19):
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.
Speaker 2 (10:38):
In my mind.
Speaker 3 (10:39):
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,
(11:07):
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.
(11:31):
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
(11:54):
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
(12:17):
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,
(12:42):
and for another like wul rails approach, we.
Speaker 2 (12:45):
Have like those numbers of.
Speaker 3 (12:47):
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.
Speaker 2 (13:05):
Man, I can explain it, but it's gonna take some time.
Speaker 4 (13:09):
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
(13:29):
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.
Speaker 6 (13:47):
Right.
Speaker 4 (13:48):
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.
Speaker 6 (14:06):
You know, we're not even talking about.
Speaker 4 (14:08):
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.
Speaker 5 (14:19):
I think there's always going to be more churn in
the front end than the back end.
Speaker 4 (14:25):
That wasn't my conclusion, but you're welcome to make that conclusion.
Speaker 3 (14:29):
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.
Speaker 2 (14:44):
Pictures of little dudes.
Speaker 3 (14:46):
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.
Speaker 2 (14:57):
Rugby Critick, but those are numbers.
Speaker 3 (15:01):
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.
Speaker 2 (15:19):
And most of.
Speaker 3 (15:21):
The tools give us very low level hints on code quality.
Speaker 2 (15:26):
And we tend to think that rubocop hints are.
Speaker 3 (15:30):
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.
Speaker 2 (15:42):
And now let's say we take the same.
Speaker 3 (15:46):
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.
Speaker 2 (15:56):
So since all.
Speaker 3 (15:57):
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
(16:20):
an army.
Speaker 2 (16:20):
It's not very convenient.
Speaker 3 (16:22):
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
(16:43):
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.
Speaker 2 (16:59):
Property of this picture.
Speaker 3 (17:01):
And actually, there is a thing called channal faces, and
it's used.
Speaker 2 (17:07):
You can google for it.
Speaker 3 (17:08):
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.
Speaker 2 (17:23):
Like, I don't know, it's.
Speaker 3 (17:24):
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
(17:44):
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
(18:06):
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.
Speaker 2 (18:25):
Become longer, and so on and so on.
Speaker 3 (18:28):
So now you can, like very compactly you can see
what differences, what high high level differences were added to
your system.
Speaker 5 (18:41):
So this is so that would be kind of part
of some kind of continuous integration system.
Speaker 3 (18:51):
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.
Speaker 2 (19:04):
Which already does that.
Speaker 3 (19:06):
Actually, so you can plug it to your pository and
it will start posting you pictures of those little dudes.
Speaker 2 (19:14):
Whenever you create full request?
Speaker 4 (19:16):
Does it work on Ruby? It looks like as a
gem f on a cat file.
Speaker 3 (19:20):
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.
Speaker 4 (19:28):
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.
Speaker 3 (19:37):
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.
Speaker 6 (19:57):
Should they work together or something?
Speaker 3 (20:01):
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.
Speaker 6 (20:17):
Gotcha?
Speaker 3 (20:19):
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
(20:41):
lot of more research, and I don't know marketing, sure,
but yeah, I like it.
Speaker 4 (20:47):
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
(21:09):
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.
Speaker 3 (21:19):
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.
Speaker 2 (21:35):
Because of the compactness, you.
Speaker 3 (21:37):
Can place like a decent amount of colde and analyze
it in one place on one picture.
Speaker 1 (21:42):
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
(22:03):
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.
(22:24):
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.
Speaker 2 (22:38):
Correct. Yes, that's a good example.
Speaker 3 (22:40):
I did similar thing in my talk in a trubconf
I just took another talk of Sandy Mats where she
was doing exactly that.
Speaker 2 (22:51):
She took one huge class and step by step.
Speaker 3 (22:55):
She splitted it into something like fifteen smaller classes, and
I basically illustrated the whole thing.
Speaker 2 (23:03):
So and yeah, you can see it in the talk itself.
Speaker 4 (23:08):
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
(23:29):
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,
(23:50):
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.
Speaker 1 (24:04):
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
(24:25):
other than a to do doing or done.
Speaker 5 (24:28):
The most important column which is that won't do column.
Speaker 1 (24:32):
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
(24:52):
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
(25:14):
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.
(25:36):
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
(25:58):
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.
Speaker 3 (26:17):
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
(26:39):
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.
Speaker 6 (26:55):
I think.
Speaker 4 (26:55):
So I definitely am really into this image thing. I
think I also agree with you, Dave right.
Speaker 6 (27:00):
I agree.
Speaker 4 (27:01):
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.
Speaker 2 (27:21):
Well, how did you get the seven?
Speaker 6 (27:23):
All right?
Speaker 4 (27:24):
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
(27:47):
have a large screen here, and that visually takes up
the whole screen if I'm on my laptop screen.
Speaker 6 (27:51):
I think the seventh column is hidden. You know, it's not.
Speaker 5 (27:54):
Good screen can board.
Speaker 4 (27:57):
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,
(28:18):
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.
Speaker 6 (28:27):
So we're just talking.
Speaker 4 (28:28):
About a high bandwidth communication solution for something that's a
problem right now.
Speaker 6 (28:34):
It's just an easy cell, I think.
Speaker 5 (28:36):
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.
Speaker 3 (28:52):
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,
(29:13):
and like, yeah, it's it's it's obvious.
Speaker 5 (29:16):
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,
(29:37):
and you can assign the regurgitations to the dudes so
you can see which classes are being physically sick.
Speaker 6 (29:47):
I did just look through the repo.
Speaker 4 (29:49):
There's nothing about failing tests like and the guy throwing up.
Speaker 6 (29:53):
It's not implemented yet.
Speaker 5 (29:54):
But that's my weekend gun.
Speaker 1 (29:58):
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.
Speaker 5 (30:18):
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.
Speaker 2 (30:38):
Correct, not exactly like this.
Speaker 3 (30:41):
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.
Speaker 2 (30:54):
So it means like you get it right.
Speaker 5 (30:58):
It's a complexity score.
Speaker 3 (31:00):
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,
(31:21):
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.
Speaker 2 (31:36):
This is all internal complexity.
Speaker 3 (31:38):
And external complexity is where you have small.
Speaker 2 (31:44):
Classes but you have tons of them.
Speaker 3 (31:47):
So basically, the point I was making in the end
of my talk after I illustrated send them stock is
that complexity actually.
Speaker 2 (31:56):
Didn't go away, it just changed the form.
Speaker 3 (31:59):
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
(32:20):
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.
(32:42):
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.
Speaker 4 (32:52):
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,
(33:16):
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
(33:38):
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
(34:00):
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.
Speaker 3 (34:16):
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.
Speaker 2 (34:31):
Like every requirement we get from the customer.
Speaker 3 (34:35):
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
(34:56):
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
(35:21):
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.
(35:42):
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
(36:06):
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
(36:29):
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
(36:51):
actually in any language, because it's nothing limits its usage
to the language itself.
Speaker 4 (36:58):
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.
Speaker 6 (37:07):
Right. Is that's what we're getting at here?
Speaker 2 (37:09):
Right?
Speaker 3 (37:09):
Yeah? You basically visualize all the trade offs you're doing,
so we you're changing this thing for that thing.
Speaker 2 (37:17):
This is what you get.
Speaker 5 (37:18):
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.
Speaker 3 (37:34):
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.
Speaker 4 (37:42):
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.
Speaker 6 (38:02):
It don't look like small arms. Yeah.
Speaker 2 (38:04):
Of course, as I said, it's a prototype. It's a
very simplistic pictures.
Speaker 3 (38:09):
But yeah, they're still able to express the initial Leadzier.
Speaker 4 (38:13):
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.
Speaker 6 (38:20):
I think we're good.
Speaker 2 (38:21):
Yeah.
Speaker 4 (38:22):
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.
Speaker 6 (38:41):
I bet you could do this.
Speaker 2 (38:42):
Yeah, that would be great. Yeah, and please give me
some feedback.
Speaker 1 (38:47):
Cool. If if people want to follow you and see
what you're doing online, where should they go?
Speaker 2 (38:53):
So on Twitter? I I am, I an E m IM.
Speaker 3 (38:58):
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.
Speaker 1 (39:20):
Awesome. Let's go ahead and move on to some picks. Luke,
do you want to start us off?
Speaker 5 (39:25):
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
(39:48):
check them out linodelinode dot com.
Speaker 1 (39:52):
Awesome, And John, do you have any I do?
Speaker 4 (39:55):
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
(40:17):
to be at home, you know, just like reminded.
Speaker 6 (40:19):
I've been doing my push ups and sit ups again.
Speaker 4 (40:22):
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.
Speaker 5 (40:33):
I've got to ask how many push ups can you do?
Speaker 4 (40:36):
How many can I do? Or how many do I
do every day? Because those are completely different numbers.
Speaker 5 (40:41):
Well, I want to note both the numbers.
Speaker 4 (40:43):
Okay, well I can do about fifty or sixty and
one go, which is I don't know, it's okay, God.
Speaker 5 (40:51):
You're going to end up looking like one of the
Ivans Method people.
Speaker 4 (40:54):
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.
Speaker 6 (41:02):
But no, I I do.
Speaker 4 (41:04):
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
(41:27):
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,
(41:49):
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
(42:11):
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,
(42:31):
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.
Speaker 6 (42:51):
That's my pick.
Speaker 1 (42:52):
Cool and avone, Do you have any picks?
Speaker 2 (42:56):
Nope, I actually didn't prepare anything. Well.
Speaker 3 (43:00):
I would say if you never tried, try using If
you're into vs code, try using viscode remote.
Speaker 2 (43:09):
I switched to.
Speaker 3 (43:10):
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
(43:31):
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.
Speaker 1 (43:45):
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
(44:05):
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
(44:26):
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.
Speaker 4 (44:42):
So have another episode on that stuff so that you
can talk about how your views have evolved or not evolved.
Speaker 1 (44:52):
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
(45:13):
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.
Speaker 6 (45:32):
Cool. But also i'd give a thumbs up for Riek two.
I do use it, and I do love it. Right.
Speaker 4 (45:38):
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.
Speaker 1 (45:47):
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.
Speaker 6 (46:02):
Yeah, I vaguely recall it. I'm just checking out it
is standard IV that is the same yep.
Speaker 5 (46:06):
Cool?
Speaker 1 (46:07):
All right, well, Ivine, I appreciate you coming on and
talking with us, and that's a wrap.
Speaker 2 (46:13):
Thank you guys, thanks swimming lights and me.
Speaker 6 (46:15):
Thanks for coming.
Speaker 2 (46:16):
Yeah.
Speaker 5 (46:16):
Thanks, that was really really interesting.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.