02:06 - EdgeCase => New Context
03:23 - SOLID Principles
04:18 - Object-Oriented Design
08:28 - Interface Segregation Principle
10:13 - Enumerable
14:07 - DCI
15:17 - ActiveModel::Lint
16:38 - Single Responsibility Principle
19:30 - "An object should only have one reason to change."
30:34 - Single Responsibility Principle Violation
31:26 - Connascence
38:30 - Duck Typing
JOSH: In driver’s ed they always told us to aim high in steering, so shooting for the horizon is usually the right thing to do. [laughter]
DAVE: You either had the worst or the best driver’s ed class ever.
JOSH: They played us that great prom night video. It is called like “The Last Prom”, where the kids get drunk and then get in the car and drive to prom and they all die. [laughter]
JAMES: So, is this driver’s ed or sex ed or what?
JOSH: It was driver’s ed.
DAVE: It was combined, you know. [laughter]
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to Rubyrogues.com/newrelic]
[Hosting bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[This episode is sponsored by JetBrains -- makers of RubyMine. If you like having an IDE that provides great inline debugging tools, built-in version control and path completion, then check out RubyMine by going to JetBrains.com/Ruby]
CHUCK: Hey everybody and welcome to episode 60 of the Ruby Rogues Podcast! This week on our panel we have Avdi Grimm.
AVDI: Hello from Pennsylvania!
CHUCK: We also have David Brady.
DAVE: Good morning! I have a fresh new bag of innuendo, all ready to go. (If you know what I mean.)
CHUCK: (laughs) We have James Edward Gray.
JAMES: Why do you make me follow him? Come on.
CHUCK: Josh Susser.
JOSH: Hey everybody! It’s great to be back. I had a few weeks off to go deal with my start-up stuff and that went well and happy to be back on the show.
CHUCK: I'm Charles Max Wood from devchat.tv and this week, we have Jim Weirich!
JIM: Hello there! I'm just happy to be here.
CHUCK: Alright. Well we haven’t had you on for a while; do you want to do a brief introduction so people know who you are Jim?
JIM: Okay that's fine.
JOSH: Because nobody knows who Jim is.
CHUCK: Jim: define. Go ahead Jim sorry about that.
JIM: Oh, I'm sorry! You wanted me to introduce myself. I thought you guys were going to introduce me. Okay, so I'm Jim Weirich. I work for EdgeCase -- a New Context company. (We got to say the entire thing now since we have been bought). I've been in the Ruby world since like, forever. And just really love Ruby and love other technologies as well. Particularly interested in the topic today, the SOLID principles and have lots of opinions on that. So, I guess that's why I am here.
AVDI: And also a fantastic Ukulele player, right?
JIM: I love Ukulele. I play guitar as well, I do some drawing as well, yeah a bunch of interests there.
JOSH: We were talking earlier about how awesome it would be to have a Ukulele version of the Ruby Rogues theme music.
JAMES: That's awesome. Yeah true story, Jim Weirich has actually drawn the Ruby Rogues while we were wearing great, great hats.
JIM: That’s right! Yeah. At Rails Conf, I sketched a little montage of the five of you up on stage.
CHUCK: Yeah. That was fun.
JAMES: So Josh is also really excited about this episode because it’s going to be one hour of definition. [laughter]
JOSH: Okay, somebody define SOLID! [laughter]
JAMES: Ready, go!
CHUCK: Not liquid, not gas? Somebody made that joke earlier.
JAMES: So Jim, you’ve talked about SOLID principle a ton. I actually went to find the link to the speech. I’ll find the speech where Jim discussed it and I’ll post it to our mailing list, so people can watch it and get ready for the show. And actually, what I found was a link to like 5-6 speeches that all mentioned it.
CHUCK: Yeah, you know more about this than Uncle Bob.
JIM: I doubt that truly. But Uncle Bob is the originator of the SOLID principles, right? At least he is the one who put them all together in a single cohesive piece. He pulled from other people as well. So, the SOLID principles are a part of a larger set of principles that deal with object oriented design. The SOLID principles in particular are ones that deal with object design. There’s also some principles on module level design and architectural level design as well. But the SOLID are the ones deal with specifically individual object design and how objects interact with each other at that very basic level.
JAMES: So SOLID, is it an acronym? Is that what they call it where each letter stands for different principle?
JIM: Yeah, so there’s five principles and let’s see if we can remember all five. So , SOLID; “S” is for Single responsibility, “O” is for the Open-closed Principle, “L” is the Liskov Substitution Principle, I is the… umm... Oh, gosh I can’t remember.
AVDI: Is that “inject”?
JIM: “D” is the Dependency Inversion Principle. Not injection Principle, but inversion principle.
CHUCK: It says “Interface Segregation Principle”. Thank you, Wikipedia. [laughs] I mean I knew that off the top of my head.
JIM: That's very good. Just Wikipedia right off the top of your head.
CHUCK: That's right.
JIM: Do we talk about the principles individually or do we talk about them as a group?
JAMES: Yeah, let’s start with why are these important together collectively and then we can get in to the individual ones.
JOSH: Jim, let’s set the level before we dive in to all the individual principles. Because you touched on this just a moment ago about whether these are architectural principles or what have you. When we were at the Rogues panel at Rails Conf, Avdi talked about how most big systems turn into object oriented systems over time. They just evolve to that sort of pattern in the large. But I think that when you are using SOLID and focusing on stuff, you are really thinking about things as you are writing classes and methods and figuring out how they interact with each other. When you think about SOLID, which part of the application development or the system development are you thinking about?
JIM: SOLID in particular to me is the individual object design or how any objects relate to another objects in the groups of objects around him-- as opposed to partition all your objects into subset of modules and libraries that communicate with each other and work with each other. There’s other principles in that, but SOLID is just right smack-dab in the midst of the object to object level and talking about at that point. I think it is probably good to point out as well that SOLID principles were enumerated at a time when static languages was all the range with object oriented design. I mean, this is back in the late 90s, early 2000 timeframe, when Java is real big, C++ is real big. And these principles primarily came out of the experience with those two languages. So, that raises an interesting question of, “How do these principles where enunciated with languages like Java and C++ in mind? How do --- those very different language like Ruby or Smalltalk or the more dynamic object oriented languages?
JAMES: You know, that is a really an interesting point when we were waiting to do the show, I went back and watched your 2009 talk at Ruby Conf, where you covered each of the solid principles. And then I also went and watched Sandi Metz’s talk at GORUCO and she covered them as well -- the solid principles. And her approach on a couple of them was because, “Because you use Ruby, you pretty much don’t need to worry about this particular principle.” But, you actually took a different approach in your talk and said, “Well, it’s true that Ruby does this for you as long as we get it wet.” And I think in particular the “I”, the interface segregation principle is the one in particular that she pretty much blew off and you actually went into and why duck typing is important and how if we don’t do that correctly, then we don’t get that benefit for free.
JIM: Right. So what I was trying to do is I was trying to get behind the principle. So if you say that this is true in Java, if it is important in Java to segregate your interfaces, is there similar principle in Ruby that we should be looking at? So, kind of getting behind the principles to the meat of it that pushes it.
AVDI: So what is the meat with that one?
JIM: The interface segregation principle? So the purpose of that is-- have you ever (I know how many of you have actually worked in Java or had a lot of Java experience, I'm sure some of you have at least) have you ever gone to implement an interface? And so you implement the interface and it turns out there is a bazillion methods in that interface that you need to implement just because it’s in the interface but have no particular purpose to what your class is doing?
JOSH: No. That's never happened to me. [laughter]
AVDI: An interface which is way too wide.
JOSH: Jim, that doesn’t just happen in Java, that happens to Ruby even. It’s like on the one hand you have Enumerable, which is great that's a very small interface. If you want something to be enumerable, you just implement each and you’re good. But then if you wanna have something that duck types to pretend to be a different class, so if you wanna have something that acts like say a string, that's a very wide interface to implement. And if you only wanna have something act like a small subset of the string’s behavior, there is a lot of overhead with doing all the other methods.
JIM: Which makes it really interesting because it changes from a principle about designing interfaces to a principle about how you write your client software that uses another object. Example is in the XML builder object, you passing a target object that the XML builder builds into and the rule is, in this library only ever uses the shovel operator, the less and less operator to put stuff into the target object. Now you can pass a string for the target object, you can pass in a file for the target object, you can pass in anything that implements the shovel operator. But because your client software, the software using this object, using the interface essentially, is using only a small part, that is an easy object to mock out for testing, it’s an easy object to substitute in some other kind of thing and all you have to do is support a single method for that to work. And that is an example keeping your interface narrow; it becomes a rule for a client software rather for the person designing the interface.
AVDI: That's really the point and kind of on the flipside of that, we talk in Ruby the closest thing we have to talking about something like interfaces when we say something like an I/O like object. And that's a bit vague really. I mean, what is an I/To like object? Is just an object that can respond to the shovel operator and a couple of read methods or is it like the entire I/O?
JIM: That's why I really like things like the shovel operator, which has become an idiom for putting things into another object, and lots of different objects of various shapes and sizes support the shovel operator and makes it really handy to do that. Other things – someone mentioned the enumerable interface. If you define each - the entire array of enumerable methods on that, but then you can assume some thing is numerable and you got enumerable method and you stick to those, and stay away from, say, array specific operations or set specific operations, then anything with enumerable can be used by your library.
JAMES: I think we do actually have more examples. For example, you can use array as a stack or a queue or things like that. And we can usually boil those down to just a couple of method like push and pop. We are starting to see that spread to other arrays for like Resque and stuff, you know, has queue and enqueue, which is basically same thing. And Rails is now trying to standardize that particular interface.
JIM: Actually, Aaron’s talk at Rails Conf have a hit on that as well, in that he wanna define how queues operate in Rails and he didn’t want to actually provide an implementation, he just wanted to specify what interface everybody will be using. Again, narrowing the interface down to exactly what you need and only using that.
CHUCK: So what about on your own objects where, maybe you have a set of objects that aren’t necessarily sub classes or super classes of each other but need to implement at least some of the same interface for interacting with another object in your system? So you are basically defining your own interface; you are not using the standard one that comes out of Ruby or Rails or something. How is the best way to do that and if the object doesn’t need it, then you wind up doing something like DCI or something? Does this fall under this principle or am I mixing it up with something else?
JOSH: I was actually going to say that DCI is a particular codification of this in a particular area -- so that is an example to look at. Sorry, go ahead Chuck.
CHUCK: That was my question. That was pretty much it.
JIM: I think it’s interesting because it hits on a couple principles right there. You are designing interfaces – so small interfaces of the interface segregation comes in. You said maybe it doesn’t belong in the object, so the single responsibility principle shines in here at this point. So, I’d say it touches on a couple of different things. I'm going to throw this out; if you are defining a particular interface that's custom for your app, if you expect several objects to conform and especially, if you expect the user of your library to provide objects that conform to the interface, I think the best way to specify that interface is with a test that you can say, “Objects of this protocol, act like this.” and provide a test that users can use their own thing to test their own objects.
CHUCK: Kind of like ActiveModel with their Lint test?
JAMES: Yeah. I love ActiveModel’s Lint Test. I was going to say that sometimes, we do have other interfaces. For example, I was working in an application the other day and I needed to return what was always some subset -- these contents and account of the total contents. And after a while, I realized that that was just a paginated list and I actually started just returning the paginate collection in that example, because that is exactly what it is; some subset with the count ---- to build things. It was interesting.
CHUCK: Right. So you are copying somebody else’s interface.
JAMES: Right. Instead of making up one of my own.
CHUCK: And that’s always nice because then it makes it somewhat interchangeable or completely interchangeable if you matched the entire interface of the entire API.
JAMES: What was awesome about it is I didn't realize I was getting the pagination links when the first starting building it but then once I used the real paginate collection for that, I was able to just give them pagination links to go through the rest of the subsets and it was great.
CHUCK: So I'm a little curious too about some of these other ones like the single responsibility principle. Is it possible to take that too far? Because it seems like you can look at an object and it has some method that does something and you can decide that it doesn’t necessarily fit in with the core responsibility of it in one way or another and so you wind up pulling it out. Or I have seen people create classes that do a particular job like incrementing an integer and things like that, that it seems like it’s overkill. Anyone?
DAVE: Moving on to--- [laughter]
JIM: I think single responsibility principle is probably one of the basic principles in here if you’d come away with out of anything out of SOLID, this one certainly applies to Ruby as much as ever did to Java or C++. The idea the single responsibility principle is so that if something needs to change, those changes tend to be in the same object, or in the same small collection of objects. That is kind of the idea behind it -- keep your responsibilities small, so that if some area of responsibility changes, that's the object that is responsible for and changes it.
DAVE: I had that same problem with the single responsibility principle that, oh, so you are just making everything so stupid that it can’t possibly work, until somebody explained to me the composed methods and the composed class concept. And SRP is really just composed class. It’s not that the class should be as simple as it possibly could, but rather that everything that happens in that class is as the same level of abstraction and is doing the same thing. You can have a class that brings together three other things and orchestrates their stuff but, if you have to make a change to that class -- to the way that class behaves, you should only have to change that class. If you end up having to change two classes to make the change work, you have violated SRP.
JAMES: Yeah. I find that one – that is one of my favorite principles. I think that is one of the most important. But I do find it pretty subjective. Like, what denotes the single responsibility seems to depend on which view I take of it. Like if I say, “Oh this is modelling an HTTP request”, then that means it involves things like body and some headers and things like that, whereas it’s also reasonable you could argue that a set of headers is its own object. So it seems like it depends on where you take the view from is what exactly is a single responsibility. Because of that, I tend to prefer the definition that an object should only have one reason to change, which is probably the best way I think to say. But even so, I still think it’s really subjective and depends on what level are your viewing the system at.
JOSH: Right. So I think that David touched on it just a moment ago where you talk about changing things and if you trying to change your one little bit of functionality or the operation of your software and if you have to go in more than one class to do that, then you are probably going to need to refactor things. One of the hard things about principles is knowing how much to apply them; how often to apply them, where do you wanna focus on them. And if you are just writing a piece of code and you are going to put it on a computer and run it and never touch the code again, then it doesn’t matter so much because you have written the code and the technical debt with it will never have to be paid down and you will never have to touch it again and you are fine. It doesn’t matter whether something is single responsibility. So the point is that, as you are moving forward and working with the code and maintaining it or fixing the bugs or adding features, whatever you have to do, that it’s structured the right way that when you make a change you only have to change it in one place. So, how you slice and dice it depends on what kind of changes that you are going to make in the future. And we don’t have crystal balls and we can’t really tell with certainty how that is going to change in the future, but we could make a few good guesses based on how to things go usually. So the single responsibility is really about, “OK. I have done this thing a couple of times before or something similar to it and I know that it’s likely that I am going to have, ‘it’s the user object and the user has some friendship with other users’ I know that is probably going to be something that I have to deal with in some way, so I’ll just put that in the friendship object.” JIM: The point about this being driven by changes I think is very good. All of these principles are not proclamations from on high telling us, “Your code must work like this or else.” They are observations when you follow these rules, then changes tend to be in one place and it’s easier to maintain. And so you watch your code and you say, “Oh. this particular object is getting lots of changes. Every time I got a new change request, this object is touched.” That's a high indication that probably, you doing something wrong in there and you begin to look at it for like, is it falling in the single responsibility or maybe thought it was but it is really not. But you have to rethink what you have to do. So, yeah a lot of this is subjective, but that has always been driven by the maintenance on the system and how to make that as easy as possible. And you’d have to be kind of self-aware when applying these principles and think, “OK, is this really helping me or is it not?” and kind of evaluate it from that point of view. AVDI: What I see often is when somebody is more of a novice, it can be really hard to make these principles concrete. Like, you’ve got the principles and then you have code in front of you. And you might not even remember what all SOLID stands for. I'm curious if you have some examples of types of pain -- like pain points in software. Like, common things that's is like, “This is really starting to annoy me” that should lead you back to one or more of those SOLID principles. That’s like, “Now that rings a bell. I should look at this Principe again and see how I can improve my code by applying it.” Not even code smells, because code smells I see code smells as something that are like, f you’ve have the pain in the past and you have done something many times, you began to think of a certain thing as a code smell maybe before it starts hurting you. I guess what I'm more interested in is, what are the pain points – what are the things you might not have identified the principle behind your pain, but you know you are feeling pain. You know you are not as happy or you are not developing as fast or whatever.
DAVE: I wanna hear Jims answer but when he is done, I’ve recently been forced to come up with a good answer to that question and to find a good way around it. But I want to hear Jim’s answer first.
JIM: Actually, why don’t you go ahead.
DAVE: Test first. Recently I was coaching a team of very intelligent people that didn't know all the Rails idioms and they had come from Java. And they were bringing their design pattern heavyweight approaches to everything. And they would get to this point where they would just start writing code and this 200-line method would be merged. And then they would go back and try and test it. They wrote something one day, and they didn't test first and the next day I told them, “Well, we got to put this under test.” and I found out that we couldn’t. And the reason why is because that their class was writing to the file system -- it was opening Net HTTP connection and doing some raw manipulation on S3 buckets – it had spidered out and it got its tentacles at five different sub systems. And I look at this and I said, “In order to test this class, I’ve got to mock out five major subsystems. If we have done this test first, we would see that this method and this method have nothing to do with each other and the test would have shown us that these have nothing to do with each other. These are totally completely different stories. This needs to be separated out.” Secondly, we would have known we need to do dependency inversion here on this thing – on basically Net HTTP provider and the file system provider and all of these things so that we could step those out easily and test them. And so we actually came about it in the other direction; rather than saying where are our pain points and what can we do to fix it, well we actually did things in that order -- those were the pain points. And the thing that we found that could have fixed it for us was test first; just relentlessly test first. So that was my answer to that question.
JIM: I think that is a really good answer too. You always look at your pain points to see where you are having pain. And you can go to any project and you say -- ask them, “What areas of the code you hate to go into and change?” and I can guarantee you just about any project will have an area that they all hate – there's where you start looking.
CHUCK: So what kinds of do you usually see in that quagmire?
JAMES: I was going to say that a lot of times, we these principles as kind of things that you do upfront to keep yourself out of trouble. And as Josh says, especially if it’s a situation that you are familiar with, then that's great and obviously you would do that. But a lot of times, it’s a lot easier to recognize them in retrospect, right? Like Jim talks about it -- you can ask anybody what is the part you hate to go in and change and they have an answer and that one is probably the source of some of that pain. There was a really good article recently on the Plataformatec blog about why web framework should not adopt the Rack API by Jose Valim. And it’s a very good article. Everybody should go read it. He doesn’t hate Rack; he likes Rack and talks about the good things it does. But, what he found is that Rack is boxing Rails into a couple of corners and they are trying to fight to get out of those corners. And its due to some of the ways that Rack is designed. And if you go and read that article and keep that open and closed principle on mind is do its pretty much a description of that, in my opinion. But what they really Rack just hands you that request and expects you to hand back a response and what Jose is saying they need in order to good streaming in Rails is they really need some kind of request that falls the open closed principle where they can say, “OK. Do this before the request and do this after the headers are sent.” and stuff like that that allows them to hook in those various points. So they can handle a process like streaming where they need to keep the connection open for a time instead of just returning some ready-made response. It’s really an interesting reading about what they have learned working on this and I think that is how a lot of these principles come about; it’s easier to see them when we are in that kind of trouble.
CHUCK: I think the hard thing though is just even then you come up with these principle and then you began to wonder, and again I think Avdi kind of hit it where its, “What's the concrete thing that I can do to fix this?” What is the concrete example of how do I recognize that there is a problem and then what is the actual solution? Because, I mean, make it so that it has a single responsibility or make sure that it’s following the Liskov substitution principle? You know, it doesn’t actually tell me exactly what I need to change in order to make it better or what the warning signs are and then what to fix. Does that make sense?
DAVE: This is a quiet episode. I'm just going to start telling poop jokes. [laughter]
JAMES: You are looking for more of a cook book scenario is what you are saying.
CHUCK: Well yeah I don’t know if we wanna get in to that on that show, but are there (no pun intended) solid examples of kind of a cookbook style thing that will say, “This is where you are likely to have a problem with this and this is how you go about fixing it.”
DAVE: I kind of get the impression where it is more like (like we talked about earlier,) there is a here is a source of pain and it’s a general principle rather than a hard and fast law. Here's a type of pain you might experience at some level -- It might be an acute pain or it might be just a chronic pain or it might be both. And kind of like the Law of the Demeter-- it’s not no congressional passed that law. It’s just a generalized rule that if you don’t follow it, you are going to have this type of pain and this type of directional. I see SOLID – especially coming from that direction -- that if you look at the anti-pattern, there is your cookbook for the day. If you look at the old anti-patterns book, if you doing shotgun surgery, which is where you have to change four classes to make any change, then you have a pretty clear SRP violation etc.
CHUCK: So, is that – what is it -- refactoring book by Fowler?
DAVE: No it’s a pretty sarcastic and cynical book about like anti patterns of like horrible things that have gone wrong in the code. It’s like a list of code smells that have been documented. So like there is the lava flow code, which where everything is just layers and layers of monolithic crap have been poured over the top and so you can’t change anything without breaking the whole system.
JIM: Essentially, an anti-pattern is any pattern where after the fact you can say, “Well, It seemed like a good idea at the time.”
AVDI: Jim in talking about this stuff, in talking about SOLID, you have talked a lot about Connascence and that's been some of the most interesting and thought provoking and mentally useful stuff that I have seen in any talks, really. Can you talk a little bit about what that is and a few other types of Connascence and how you identify that?
JIM: Sure. So, like I said, these principles are kind of trying to get down to some engineering principles that we can follow to get a good software. In looking at these principles, I have been trying to get down to underneath those -- what are the quarks underneath the atoms of our principles and make these things up. And I stumbled across the concept called “Connascence” by Meilir Page-Jones in his book. Every programmer should know about object oriented programming and the book is in three parts; the first part is basically, if you know any OO at all, that first part is just introduction, won’t help you much. be much. The second part of the book is a notation for designing OO and the third part of the book is the concept of Connascence. The name of the book is What Every Programmer Should Know About Object Oriented Design (or Object Oriented Programming. Something like that.) So, Connascence is the concept of when you have to change program, what else needs to change. And if two separate pieces of your code need to change for one reason, because this change over there needs to change and they are connected by some type of Connascence, what I really liked about the concept, so normally we call this “coupling”. These two things are “coupled” in some manner. Everybody means something different by coupling and what Page-jones did with this concept is specify on identify different kinds of ways that software can be coupled and that they can have Connascence. So he speaks of names like connascence of name, where if I change a name over here while I'm using this name over here and this module I've got to change it over there. If you change the name of a method – a public method in your class -- every client that uses it has to change the name of the method wherever they are using it. So that is connascence of name; your library and all the client software using it have Connascence of name with each other. There is something called connascence of position, where the order or position of something in some kind of structure, if that changes other pieces of code need to change as well. The order of parameter in a calling sequence is essentially connascence of position. And so he broke this down into about 9, 10, 11 different kinds of Connascence. Some of it kind of static Connascence, some of it rather dynamic. And it was just really interesting to see all of the different ways that programs are interconnected with each other in ways that they can change and effect on the parts of the program. And I really like the fact that he gave it like, “OK. Now we can talk about these type of connascence.”
DAVE: What I love about Connascence… first of all, the word means “born together” which is great -- like the visual imagery to me. And you spoke about this in Ruby Conf about a couple of years ago and I just glommed on to this idea, like a beacon; it was just so great. And the definition that I took away from it is that connascence of x means that your code has some implicit property x, that if you change that implicit property x, the code has to change as well or the code will break. So the order of parameters -- the order of arguments in a method, if you are passing in, you know, you wanna search an array, so you got to pass in a needle and you got to pass in a haystack and you accidently pass in haystack and the needle, because you don’t have the function declaration up in front of you, you accidentally swapped those around; that's just beautiful illustration of connascence of position. Connascence of name, I took that to mean changing the name of the method, because that will obviously break if you call the wrong method name. But if you change the name of the key and the hash and you misspelled the key and the hash, you are going to break your code. I love this and this (with apologies to our editor who is going to have to bleep this), Jim, you helped me coin an anti-pattern that when I get very frustrated with a piece of code, I will refer to it as connascence of bullshit. [laughter] Because if the bullshit changes, the code breaks! [laughter]
JIM: That's good. I like that.
CHUCK: Have you been reading my code Dave?
DAVE: It’s been actually, it’s a formal definition of b.s.; it really, really, really is. There’s times in the code where you just look at something and you are like, “This is just stupid and idiotic and management wanted it this way. And oh, management changes their mind; therefore the code no longer works correctly.” [laughter] Connascence of BS. There you go.
JIM: I have definitely experienced that. Oh yes.
CHUCK: I think we all have when somebody else’s defining the requirements for the job.
JIM: But you take these ideas of connascence and you look back at the SOLID principles and you can kind of see relationships between this. For example, we talked earlier about interface segregation making your interfaces narrow. So if you have a wide interface, you've got a large dependence on a lot of different names in your interface. By making your interface small, you reduce the connascence of name between the two parts of the code that are dependent upon that interface. So, I really like the ideas of connascence, and seeing them bubbling up to the SOLID principles and naturally giving us the understanding of why the SOLID principles are beneficial
JOSH: That is interesting. Jim, I have a question about dealing with these principles in Ruby and if there are particular language features or classes in the standard library or what have you, that are particularly useful when trying to do things in a SOLID approach?
JIM: Yeah. I think the first three or so. The single responsibility, open closed and Liskov substitution are part of the entire Ruby philosophy. They are tied in there and they can be taken almost directly without change from their original meanings, especially the Liskov substitution principle. To me, the Liskov substitution principle is the definition of duck typing. We say it’s duck typed but what that means is that we can take an object and substitute it in and the program using that object continues to function as before without significant change. And that is exactly Liskov’s definition of what a sub type is. And so Liskov substitution, duck typing – they are one and the same almost. The last two; the interface segregation and dependency inversion, don’t have a direct application in Ruby. Mainly because we don’t have interfaces to segregate and we don’t have interfaces to invert our dependencies toward. But even so, the ideas behind them I mean keeping the interface narrow is still applicable to Ruby and staying away from over dependence on concrete class name is still a guiding principle in Ruby. I don’t think it is nearly as important as it is in other classes or other languages but it’s still something that gives some benefit. It makes code easier to test and to mock and reuse in other situations.
JOSH: Yeah. Jim for the dependency inversion principle, one of the smells that I think is pretty good at detecting violations of that principle is when you type a constant name that's outside of the scope of your class. And so, it seems very recent for me because I haven’t been on the show in like month, but Avdi was talking about never calling time.now within your code, but having something pass in the current time as an argument to your method, so that you are not tightly coupled to that constant definition.
JIM: We actually did that where we had -- instead of using time.now, we created a time manager object ----- to grab the time and that way, we wouldn't have to depend on time.now. That allowed us to simulate time very easily by passing in a simulated time manager object and we use that to always, always, always get the time within the application.
JOSH: Actually. So my point there was that it’s not just classes that are things that you have to worry about for the dependency inversion, but there is also well-known objects – that sort of thing. But yeah, even in your code when you are writing a class method in a class, whether you do “def self.whatever;” or “def theactualclassname.whatever;” that difference matters. I think people do it where they do that and then within the method, they actually type out the name of the class as opposed to self. So those sorts of things—I mean, not just the dependency inversion principle there because there is also the some inheritance stuff going on there in terms of the open-closed; but that's one of the smells that I always keep an eye out for. When I see people explicitly referring to class name-- some of those things are totally fine in Ruby but it is not like in Java where everything has to be glued together really stiffly. But when people are writing a code, using some class in the standard library, I usually don’t have a problem just typing the name of the class directly; that’s not a big deal. But when you are starting to build the structure of your application and different parts that are talking to each other, I think it’s pretty often that explicitly referring to a class by name gets you that sort of connascence that can get you in a little bit of trouble down the line.
CHUCK: Alright. Well, unfortunately, I have a hard stop in about ten minutes so, we need to get into the picks. So, I hate cutting these things off early especially when we are having a good conversation about it but I'm going to. So let’s go ahead and get this started. Avdi, do you want to start us off with picks?
AVDI: Sure. Here is a none code one; for a few years now I have been using like the traditional safety razor for shaving. And there's a whole around shaving these days and people go on and on about which razor and which razor blade and which tape of bristles on their shaving brush etc. but even if you never get into all that stuff, using a traditional safety razor which takes double edge razor blades is a really cheap option. If you have any hairs on your body that you like to shave, you buy a decent razor for like $50 and then the blades cost pennies. And when I compare that to what I used to spend on my cartridges for three there's just not comparison. So that's worked really well for me. Just safety razors. Merkur is a good brand but yeah, safety razors. I think I will also pick as a little bit more code oriented, remote pair programming on open source projects. I don’t really advertise this, but I sort of make a bleak reference to it from time to time, that pretty much everybody who wants to get in touch with me and I’ll schedule. Like if they wanna work in some open source code and we can just pair up for two hours and work on something. And I often go into those feeling like, “Oh I’ve got a pair programming appointment tonight and I really just want to relax.” And then invariably I come out of it feeling great, feeling energized. Maybe I learned something, maybe I was able to pass some knowledge on and whatever else. I often meet someone new from across the world and share perspectives. So, I totally recommend this like you can get in touch with me you can get in touch with-- I think probably a lot of people would enjoy this. If you have somebody that you would be interested in working with. I mean, I'm not telling you to go out there and just annoy people, but like, if you have somebody you wanna learn from, hit them up sometimes. Say, “Hey, can we like screen share sometimes and maybe we can share knowledge, work on some open source code, get out there in the community.” And you don’t have to be in a tech hub and in a co-working space or in a café that all the programmers hang out at in order to work with somebody that you wanna share knowledge with.
CHUCK: Sounds great. I may have to take up on that. Alright James, what are your picks?
JAMES: All right. I’ve got a few but I will do them quick. First of all, I know we’ve sung praises about RailsCasts in the past and obviously, that's still holds true today. But definitely go back and see the last two episodes if you haven’t -- they have been on security. And really great super practical dive into web application security that are really great. I'm so glad Randy is doing that and I hope he does some more of that in the future. So, those are great episodes. Then I'm on vacation this week, so all I'm really doing is goofing off. So the rest of my picks are about goofing off. First of all, a buddy of mine told me I needed to go watch the Dragon Tattoo trilogy, but not to watch the movies -- to go watch the six parts Swedish miniseries. And I have been doing that and its absolutely amazing. So I highly recommend that people go check that out. Its available on streaming on Netflix and its six parts and each part is like over an hour and a half. It’s just absolutely epic and huge and awesome thing. The lead girl is a hacker by the way . So, just absolutely excellent. And then another thing is my wife and I wanted to grab just a fun game to play around with while I was on vacation and we do that a lot. This time we picked up Dungeon Defenders. It’s available on Steam. And it’s pretty awesome little tower defense game where you run around setting up the defenses the way you want then and you start it. And the bad guy starts pulling in and you could run around repairing your defenses jumping bad guys yourself so you can get involved in the fight and stuff. It’s a whole lot of fun. You can play it online with other people, so it’s great for just getting a quick game with your wife if that's what you wanna do, like I did. So, all kinds of fun stuff. Enjoy.
CHUCK: Nice. I was just looking up The Dragon Tattoo, that's Swedish with English subtitles?
JAMES: Yes. Correct. So you have to do some reading but it’s totally worth it. What a great series. JIM: I saw the Swedish version. It’s really very good.
CHUCK: Awesome I have to check it out. David, what are your picks?
DAVE: Okay. So, I always say, “I'm going to do this quickly.” then I fail to do them quickly. So I'm going to do my best to do them quickly by leaving out a lot of data. I recently got asked almost in the same conversation how to raise kids -- I don’t have any. So that is a funny question for me. And also how to be a good team lead, how to be a good manager. And I laughed and I said, “Let me give you the two best books on how to hack your wetware or how to hack somebody else’s wetware.” The first book is How to Behave so Your Children Will To. It’s by Sal Sever. And its hands down the best book on managing people where there is a power negotiation. I say I don’t have kids but I did help raise teen agers for about five years, so I do a have a little bit of experience in this department. And this book isn’t about—no, I'm just going to leave the data out. I will just say, this is the single best book on understanding the wetware of a teenage mind and how to get three steps ahead of it, so that they become engaged with basically in their own discipline and making their own choices and consequences. The other book on managing people is called “The Dog Whisperer: A Compassionate, Nonviolent Approach to Dog Training”. This is not by Caesar Milan this came out way before Cesar was a thing. So, this is a book by Paul Owens and Norma Ekroate. And this all about how to get inside your dog’s mind and understand what your dog is thinking. The basis of the book is that a really smart working dog can learn about fifty words of human language in about five years – if you train them really well. But as human being, you can learn 200 words of dog in 2 weeks -- if you are willing to sit down and learn to speak their language. And if you train a dog so that the dog understands that it can communicate with you to get her needs met, you end up with a much happier dog; because now you have a dog that believe that she has a control over her environment and knows how to interact with you. And both of those are the two single best books that I use for manipulating other people –and my secret is out. So, basically they are two books on how to be humane to other people and to dogs and children. So, there you go.
CHUCK: Josh, what are your picks?
CHUCK: The mute button is one right?
JOSH: Yeah, I love that mute button; I use it all the time. I haven’t had much time for coding lately. I have been neck deep in start-up stuff and that was really fun. I'm not going to talk about it now but I will talk about something else that I was doing that was non coding and that is Golden Gate Ruby Conference. Okay, we always sell out so if you wanna go to the conference, just go register now. And I just wanna to let people know that you just pay the standard price. We don’t have any sort of like, discount for groups or anything like that because we always sell out. So it’s just not really something that we do. But the call for proposals is open right now and it’s going to be open through the end of June. So if you wanna come speak, just go to the gogaruco.com website and there's a link to submit your proposal. We are already getting some really good ones. I'm excited. OK. So, enough self-serving. Now something about serving society; go to defendinnovation.org. I don’t know if you guys has seen the site, but it came up a couple of days ago. Something that the Electronic Frontier Foundation put up -- I am a proud member and I support them in their agenda to make software look more sane especially legally. So, defendinnovation.org is about fixing the seriously broken software patent system. So if you have some thoughts about that, you can go and you can see what their position is on it. It’s an online petition; you can add your name to it and comments and these will be delivered to congresscritters to try and get them involved in a discussion about how we improve the state of legislation around software IP. So I'm kind of excited that they are gearing up to take this battle on; it seems like it’s about time. And then I have a pick for an information source. So I know a lot of developers are getting in to doing start-ups and finding their own businesses and eventually you have to think about funding -- unless you are super lucky and can bootstrap yourself up from nothing without anybody’s help. So there is a blog of a guy named Mark Suster (I feel bad for not being able to pronounce a name so close to my own [laughs]) So he’s at bothsidesofthetable.com. This is a guy who was an entrepreneur, raised money and now how is a VC and invests in people’s companies. And he has some of the best information writing on the funding process and running a start-up and interacting with investors. So I would recommend going and reading his stuff. It’s great that he takes many of his blog posts and will put up and article that organize the path through reading them. So he makes the information very clear and lays it out well. I found it really useful. So, okay that is it for me today. I'm expecting next week I’ll have some that are actually about coding.
CHUCK: I’ll go next. My first pick is an app for the iPhone that I have been using to get in to a better shape; it’s called “Run 5k”. It’s basically the Couch-to-5K program and its really because effectively, what you do is you turn it on and you can keep playing your music while it does it. But what it does is it turns your music down for a second and it says, “Run now.” or “Walk now.” or whatever stage you are at in the half hour run that you are doing for Couch-to-5K. So I literally just struck to arm, hit play and tell it to start the work out and then I just do what it says. I just finished week five work out one, day one. And it was rough, but I got through it. I really, really like it. So, that is one thing that I have been doing. And then usually, I wind up go and lift weights for fifteen twenty minutes after I go for half hour run. The other thing that I am going to pick is -- there is a podcast that I have been listening to and they also have a mailing list over copyblogger.com (or is it .org? I don’t remember). It’s Internet Marketing for Smart People. They have the podcast; I really enjoy it. They get the people like Seth Gordon and then they have the copy blogger folks. I've also heard episodes from Chris Brogan and a few other folks out there that are just kind of these internet marketing geniuses. So you get a lot of good information from them. And so if you are trying to start a business or you are running a business and you wanna do some marketing to people on the internet, then Internet Marketing for Smart People is really a great way to go. And I get a little bit more from them because I'm also a member of the third tribe, which is an online group that talks about marketing. And they have calls twice a month and they usually have special guests coming on and talk about stuff. So, that is pretty cool too. I’ll put that in the picks as well, but if you kind of wanna get your feet wet and figure out what’s there then, Internet Marketing for Smart People. Finally, I just want to remind you all that I am working on this JSON API online training and you can find that in buildingjsonapis.com. So, go check it out. The landing page is still kind of a work in progress but it has all the information on there and you can sign up for the training there and that will be on the 18th of July I think -- it’s a Wednesday. Anyway, let’s go ahead and wrap this up.
JAMES: Chuck, we haven’t done Jim.
CHUCK: Jim! Sorry.
JIM: I was afraid I was going to be left out there. I’ll go really quick. Programming pick here for me is a really cheap one because you guys already – it’s RubyMotion -- Ruby on iPhone. I'm loving that. I’m having a ball doing that. Popular media picks; I just finished the most recent book in the George R. R. Martin series Song of Fire and Ice. And so now I'm ready with the rest of you to wait five years for the next book to come out on that. That was a really enjoyable, really gut wrenching and kills off my favorite characters, but good series nonetheless. Video pick for you, go to YouTube and search for “Pink Five”. If you like Star Wars parodies, you will discover that there was actually another Jedi involved in all the behind scenes of what was going on with the movies on Hoth and on the moon planet with the little teddy bear guys. So that's my pick.
CHUCK: Yeah sorry about that Jim, I've kind of in been in a hurry to get out. I think my whole extended family is waiting for me so that we can go to the zoo.
JIM: You have fun then.
CHUCK: Anyway, thanks for coming Jim. We really appreciate it.
JIM: Okay. Thanks for having me.
CHUCK: So, a couple of business items real quick; you can sign up for Ruby Rogues Parley on the Ruby Rogues website. We are going to be reading Growing Object Oriented Software Guided by Tests. We will be reviewing it sometime in August. I’ve gotten a tentative date on that from the authors, but we are still just finalizing everything between the two. So, other than that, we will catch you all next week!
DAVE: Actually one other thing; we have not forgotten your Rogues Golf submissions. We are getting to those.
CHUCK: Yes. Alright. Let’s wrap this up and we will talk to you all next week!
JAMES: Thanks everybody!
DAVE: See ya!