026 JSJ Code Organization and Reuse

Download MP3





TIM: I'm wondering if I should try to do the call and get cut off half way. CHUCK: [Chuckles] JAMISON: I think any Tim is good Tim, even though it cut off half way. JOE: Any Tim is better than no Tim. JAMISON: Well, not if it’s like literally halfway, of like you get chopped in half. JOE: Well, it depends on which half. TIM: You know, the top half can survive for a little bit, right? CHUCK: There you go. [This episode is sponsored by ComponentOne, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.] CHUCK: Hey everybody and welcome to Episode 26 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE: Coming to you live from a van down by the river. CHUCK: [Chuckles] Not kidding either. Also, we have AJ O'Neal. AJ: Coming at you live from the cardboard boxes of Orem, Utah. CHUCK: Jamison Dance. JAMISON: Coming at you pre-recorded. I'm actually just really good at guessing when to speak. CHUCK: Tim Caswell. TIM: Hello. Coming from Texas. CHUCK: And I'm Charles Max Wood from devchat.tv. This week, we are going to be talking about, Reusing Code and Code Organization. So on the user voice forum, (let me pull that up really fast) there was a topic about code reuse and I should have it up initially, but I didn’t. JAMISON: Do you want me to read it? I have it here. CHUCK: Yeah, that will be great. JAMISON: “I'd like the panel and potential guest to discuss patterns around augmentation, plugin-hooks, prototype copying, prototype inheritance, etc. Also, the pros and cons of each.” CHUCK: Wow. That’s a little more involved. TIM: Sounds like fun. CHUCK: Yeah. JAMISON: I think we can be sneaky and just use the title. I mean, we can talk about some of the stuff too if we want but I think the broad topic is interesting. JOE: Go ahead and paste that in the chat so I can read that one more time. It seemed like I was shutting things or so. JAMISON: Boom. Pasted. CHUCK: Awesome. All right. So best practices and patterns for reuse, it’s kind of funny because I think generally, the way that a lot of ways folks do it in JavaScript and I think we'll all agree that there are probably better ways to do it is if they have a function that they need to use in more than one place; they just make it a global variable that you know, it references the function that they are going to be calling and then they just call it willy nilly wherever they need. JAMISON: I can’t say most people do that -- at least not in my experience. JOE: Yeah, 90% of all JavaScript programmers only program in JavaScript, like an hour a week. CHUCK: Yeah. JAMISON: Yeah. I guess I'm part of the people that do JavaScript all the time, so yeah I guess if you are like a Rails guy that just needs to put some JavaScript and then be your first instant. JOE: Remember, it’s the only language that people can program in without actually having to learn the language. CHUCK: [Laughs] TIM: No. There's others, like the Java IDE will tell you what to type. [Laughter] JOE: [inaudible] works that way too: you just hit Ctrl+Space, Ctrl+Space, Ctrl+Space. TIM: It looks like you are writing a server; do you want some help with that? [Laughter] TIM: But actually, I don't see what wrong with using a global function if your code base is small enough. I mean that’s all you had in C. And C is used for operating systems; you just got to namespace your function names. It works. CHUCK: But see, you just took one step in the right direction there; you mentioned name spacing your functions. TIM: Right. Which what everyone does otherwise they’d conflict like crazy because globals are the only way to do it. CHUCK: Right. JOE: I mean, still it’s a good point; depends on really the size and scope of what you are doing; If you are putting 30 lines of code into a page, then yeah, there's no reason to worry about anything else. And you only got a couple of pages on your whole site that you are going to use JavaScript, put it into a function, you got two pages that’s going to reuse the same function, put in a function and include the file in both places, and you are good. CHUCK: Yeah. That's true. TIM: I think premature generalization is worse than premature optimization. CHUCK: What do you mean by ‘premature generalization’? TIM: A lot of programmers have the habit of thinking of every possible way the software might be used down the road and baking in a way to handle that right off the bat. And the fact is 90% of the software projects never even get finished. I mean, that is so much wasted time. CHUCK: That's true. TIM: You got to be saying it better not be sloppy, but don't waste times on what ifs that probably will never happen. JOE: So there's a really awesome cartoon, (you guys may have seen it) it’s like a three panels; the first panel, the guy asked the other guy to pass the salt. In the second panel, nothing is happening. And in the third panel, he says, “Hey, I asked you five minutes ago to pass the salt.” The guy says, “Hold on. I'm building a framework for passing arbitrary condiments.” [Laughter] AJ: That is XKCD/974. JAMISON: Wow, you have that one memorized, AJ. AJ: Not memorized, I'm just good at googling -- faster than you can speak. TIM: Plus, I've recently used it in a blog post. JOE: Well, the amazing part is… wait, was it AJ that said that? Did you have that, AJ? AJ: Did I say what? JOE: [unintelligible] …and Jamison is prerecorded, so the fact that he knew about that -- impressive. [Laughter] TIM: So assuming you have more than 100-line script and you are actually you know, like writing a real app, how should you organize your code? CHUCK: Well then you put in the $function in jQuery so that it loads after [unintelligible], right? JAMISON: jQuery puns are good ways to organize code, right? AJ: This is where you listen to Joe. Joe’s got the solution here; you have to write a code so that it’s testable and if you write it as testable, you end up with modules. Something like that, right? CHUCK: No. you got it wrong. You write the test and then you write the code, so that it will pass the test. AJ: Right. Which ends up being testable code. That's what I'm going to say. TIM: I actually don't like that method, but continue. [Laughter] AJ: I'm trying to get Joe to come out and share his knowledge. JOE: TDD it. You got to TDD it. AJ: Because he gave a presentation at… JOE: UTOSC? AJ: Yeah and the one before that at UtahJS and it was very enlightening the way that… JOE: So I wanted to point out here that I think the real problem is not for the guys that are programming in JavaScript full time and not for the guys that are doing an hour a week; it’s that middle ground… and you know, projects are moving this way more and more and more. You start getting JavaScript to people that have been doing an hour a week and just 20 lines of JavaScript in their pages and all of a sudden, they just need more. You know? People that are doing it full time, they already got this figured out. It’s everybody else; which is a huge… I would still say the majority of JavaScript programmers are people that are working on projects that are pushing their JavaScript abilities the first time that they’ve ever at that company done a JavaScript project that big or put this much code to together. It’s those people that really have the trouble and the need for help. CHUCK: Yeah. I think that's true because I mean, I'm probably the only person on this call that isn’t working on JavaScript all day. I mean, my primary in programming is in Ruby and then I do JavaScript when I have to. And most of that is actually CoffeeScript -- which is another can of worms. But anyway, so yeah, I mean, sometimes I don't know exactly the best way to handle it because my core competency is based around all of the idioms and practices of Ruby, not JavaScript. JAMISON: So we've kind of been dancing around it and saying why it’s good to use the best way to organize your code, but no one has actually come out and said what they think the best way to organize your code is, right? AJ: NPM modules, duh? CHUCK: [Laughs] JAMISON: Well, some kind of modules. I think it’s still kind of up in the air, especially in the browser. It’s not Node, if you are doing Node of course you wanna use NPM but you wanna have your code in modules. And then you have some format for including modules into other files that you can build up off of that. The issue with that is there is some overhead, we’ve kind of hinted at that -- it’s not the easiest way to just sit down and bust out something that works; there's lots of crankiness that you have to go at that setup and working. AJ: Stop perpetuating the lies! It’s easy. You just have to have the right tool. I mean the right tool is hard but that’s why we are here. Its Pack Manager. [Laughter] JAMISON: [inaudible] …and you are trying to get them to use your library. [Laughter] CHUCK: I was going to say I think he's trolling us. [Laughs] But anyway. JAMISON: It’s worth it, but you have to be at the size of project where the effort that you are putting in to organizing your code will save you time in the long run because of that. JOE: And that’s one of the most difficult things in software development is getting at some point where you need to go with something bigger, broader, more abstract and realizing it before you get too far down the road of not going there. CHUCK: Yeah. I can tell you that the way I kind of evolved was at first, I was just embedding JavaScript on the page and then I moved around to, “Gee, I'm embedding a lot of JavaScript on the page!” So then I started putting in .js files, but it was still just kind of crammed in there. And finally, things got to the point where I was like, “I really need to kind of organize this into pieces that do related stuff”. And so then I’d namespace you know, var something equals and then some object that has the properties being functions that I need, and the other properties that those functions need to work. And then eventually, I moved around to using something like BackboneJS or something when I got to the point where it was like, “I really need things that already know how to talk to each other”. JOE: So I think it will be good for us to talk about like the tiered, step-up model in organizing your code and making your code reusable because I think there's a case for not… that there's a place in between, “I'm just throwing functions all over the place inside of my HTML,” like the next step up is putting JS files. But there's a couple more steps before you get to, “I'm putting this and I'm using AMD.” I'm using Require’s JS or something else. AJ: Right. There's like Red/Green refactor idea, right? Like you start with really crappy code and you wanted to do something; you test that it does something and then you do that five times and then you are like, “Oh, I have 5 pieces of crappy code.” Then you refactor. JOE: Right. Yup. TIM: Yeah. Incremental is the key. I mean, think about how is software different than manufacturing? If you are a worker at a factory building a car, you are going to build the same thing over and over, right? The hard work is taking the physical materials and putting them together. Software is completely inverted; if you wanted to make a copy of Microsoft Office, you just copy the disc -- you don't need a programmer for that. The very nature of programming is you are doing something that's never been done before. And if it’s been done before, you probably shouldn’t redo it again exactly the same way. So it’s going to be different; it’s going to be unique. And with that in mind, you don't know what you want. CHUCK: Right. TIM: And so, incremental is the key. JOE: So I think that there's a few steps to take and the size of project kind of dictates the value of them but the first one, like what you said Chuck is, code right inside your page; the next one is putting code inside JS files -- which is still is that only for the sites that really have a small amount of JavaScript. And then the next step is one that a lot of… that’s the place where I don't think a lot of people, especially that aren’t doing full-time JavaScript are really aware that they can go to, and that is still putting their JavaScript inside files but then, putting everything inside of immediately self-executing functions and making sure that those functions are order independent -- so you don't have to worry about the order of those basically, modules. It’s not a real, true module system; it’s not AMD, but making it so that all your different code blocks can run it in an order-agnostic manner and then being able to include 4 or 5 pieces inside of a page, I'm definitely been on that level on a lot of different projects. JAMISON: And that’s the one right before using like Browserify, pack manager, RequireJS? JOE: Right. Exactly. TIM: I think there's a level between. I mean… JAMISON: What's that? TIM: There's a big difference between a module loader and a function like define. Like I can write a define system; that's 10 lines of code and then manually include script tags for all my modules and it will just work. As long as I have the right script tags in my HTML, it will all load fine. I don't need a loader. I don't need 14K of special code for all these edge cases. AJ: Well, that's what AlmondJS is, isn’t it? I mean, it’s just the 10 lines that you need say, “Oh, here's something. If you require this, look in the global else.” TIM: Well, AlmondJS even is a little more because it follows the full AMD spec and supports all these different formats. JAMISON: So what do those 10 lines do? I'm confused. TIM: So basically, you just have a function called define or whatever you wanna call it. I've done this a few times. And then… I mean, there's ways to implement it; you just store the definition in some hash and then when something requires something the first time you call the definition and… I mean, it’s not a lot of code. JOE: Well, that's really clever. I hadn’t even thought about that. AJ: Well, that’s what these compiler systems are doing; like the pack manager and the OneJS and the EmberJS; I mean, they are module loader. Some of them a little bit more complicated than others, but it’s like what Tim was saying, all they are doing is creating an object and a define function and a provide function or something like that, you know? TIM: Right. But if you don't want to buy in to some spec and some module system and have to worry about some repository, you can just write your own version of define that works for your little project and it can be entirely proprietary to your app, but it still gives you some organization. JOE: Mh-hm. TIM: So, I think that’s a step in between. JAMISON: That seems a little scary though, because you are losing all the interoperability with these libraries that are already have built-in support for AMD and common js. AJ: Well, those two systems are so simple; I don't see why you would invent something different. I mean, you have one function versus two functions. Either define or you have a require and a provide. TIM: But what if you are not aware of these? AJ: Then, you need to get aware, right? I mean, that's why people listen to these talks and stuff. I mean if somebody is listening to this, then they are already aware, right? JOE: Maybe. JAMISON: As of five minutes ago. CHUCK: [Laughs] AJ: Or 5 episodes ago. I mean… JOE: But also, being aware can be scary; like implementing RequireJS for example, for the first time can actually be a pretty daunting task and there's a lot of friction with getting it going. AJ: Well then, choose one that’s simpler. JOE: So, what is simpler? AJ: We'll, there's several of them; the hard part is finding one you’d feel good about. Like, I feel pack manager is pretty simple. Pack manager build. You have a package.json, it requires the files, simple -- just like Node. If you like Ember, you already used Ember, that one is just as simple. The OneJS… what was the one you mentioned the last week, Tim? I forgot the name of it. TIM: Jam? AJ: Jam, right? I mean. All of these really simple; Require seems to be the more robust one in that, if that one doesn’t have a compile stuff but all these other ones is just like, you type the name of the thing, you type build, right? That’s how Jam works, right? Like Jam build or Jam add or something like that. TIM: Well, sort of. Jam is like NPM for RequireJS. It still uses require in the browser. AJ: Yeah. But I mean the actual process is not a complicated process. It’s like 1 or 2 steps, correct? TIM: Sure. But then you have all these code that you don't understand and I’ve had to debug it and when things go wrong, I had no clue where they went wrong. Whereas if it was a 10-line library I wrote, then I’d understand it. I mean, that’s the difference. AJ: Yeah. And I'm guessing that the part that broke was probably where it walks the AST and it concatenates the files together and it did in the wrong order and you had to like change it so it was more careful about how it handled which dependency gets loaded first or something like that? TIM: No. It was just I was using it wrong or something is documented wrong. And that’s my point; why should I have to spend all the time learning this new system if I don't need it? CHUCK: Right. Yeah, that makes sense. And you know, a lot of times it is simpler just to put like a bare bone something together rather than trying to figure out the ins and outs are in somebody else’s systems. JAMISON: So that gets into kind of a fundamental difference too between build versus use, right? And I think part of that is just philosophical. I mean, at some level, there are some things that you don't want to do yourself, but it’s kind of wishy-washy; there are some people that will tend towards building their own thing. And I think Tim, you are definitely one of those people, where if you have a problem, you are much more inclined to just make a solution yourself. AJ: I completely agree with tooting your own horn and writing your own code just because it’s fun. But, write code that will work with other people’s code. That’s my one thing. I'm a Crockford fan; I like strict mode; I like modules; I like stuff that if you put it in somebody else’s code, it’s not going to break. That’s my one call. CHUCK: Yeah. But if your website or your Node app is really the only place that that code is ever going to be used, then… AJ: Then you should contribute more to the open source community because there's got to be some utility in it. If there isn’t, you probably shouldn’t be writing it. TIM: Right. Which brings us back to code reuse. [Laughter] JOE: So one of you guys mentioned Ember, which we haven’t even… we were discussing package manager but not frameworks. CHUCK: Yeah. The frameworks usually do provide some interesting mechanisms for that, don't they? JOE: Yeah. TIM: I mean like you get the [inaudible] plug-in system for years and years and in various things like that. JOE: Well, somebody made a joke earlier but I've been to a place where they used jQuery plugins for all code reuse. TIM: I've done that. CHUCK: So if you wanted to add JavaScript to the website in anyway, you would write a jQuery plugin that provided it? JOE: Yeah. I mean, you could go outside of it of course; you just plug it straight in, but the company basically kind of had this template; you grab it, you throw it in your code inside of it and they use jQuery plugins for everything. JAMISON: That’s just kind of a fancier global. JOE: Yeah. CHUCK: Yeah. JOE: Yeah, it’s a fancier global. CHUCK: Well, it seems like most of these is. We’re talking about modules or something that looks like a class that namespaces whatever it is but you know, ultimately when you come right out to the top layer of whatever it is, it’s a global. In fact, in most languages, you don't think of them this way, but all of your big constants like your classes and things are globals. JAMISON: I mean, if you back up enough layers, sure, but that’s like saying, if you go back to every single language is the same. It’s how easy it makes it to do things at the level you are actually dealing with it. CHUCK: Oh, absolutely. TIM: So, let’s talk about namespaces. In pretty much every module systems I've seen, there's one namespace; whether it be the window object or your AMD namespace or whatever, there's just one namespace.  And so in one instance of your app, I can’t have two different versions of jQuery -- using the module system. I have to manually alias things and do it by hand. So, most module systems are single namespace. But then you have the weird NPM system where it’s nested namespace; each module has its own name space for its own dependencies. And the goal there was so that you could have conflicting versions in the same process. JAMISON: So, it seems like if you wanna do that in the browser, you have to kind of rely on the libraries to provide non-conflicting versions like jQuery has the no conflict thing. I think Backbone has something like that too. But if they don't do that, then you're kind of … is what you are saying, right? TIM: Yeah. The Node conflict thing is just a way of staying off the window global. But I mean like, you can’t really do… I don't know of any module system for the browser that has nested namespaces. JOE: And that really sucks because most server-side languages support using nested frameworks. And so when you're used to that paradigm, you get down to the client, it’s like if you don't do it yourself, all the built in ones are just going off of a single namespace. TIM: Which isn’t a bad thing. In fact, if you look at the JamJS readme, he is purposely making it single namespace only. Because in the browser, every byte cost you and you don't wanna encourage people to have three version of jQuery just because it’s easier on them. JOE: But on the server side, it’s not just having three versions of the same thing that's the benefit in nested namespaces; it’s also just increased code organization. TIM: Yeah. I mean, there's pros and cons. But like as far as AMD versus global, as far as I'm concerned, it’s just another way to do global namespacing. You can have window.$, you can require jQuery -- its all the same. JOE: Yeah. That's very true. TIM: The nice thing about AMD is you are able to have these fancy loaders where it does your dependencies automatically and you can package them and minify them and do some of neat stuff with it that you can’t really do with globals. JOE: That's very true. TIM: So, let’s see… the question was about prototype copying, prototype inheritance and that kind of reuse. One interesting misconception I’ve had in teaching JavaScript, which I found that half my articles in teaching JavaScript is people don't understand… [silence] CHUCK: Whoa. [Laughs] JAMISON : They don't understand harmonicas. TIM: They don't understand getting muted. All right. CHUCK: [Chuckles] I kept thinking it was my kids so I kept hitting my mute and then it kept going, “Oh. Okay, never mind.” TIM: Where am I? Okay. I was saying, so let’s take a prototype; you know, the … that confuses tons of JavaScript people. And this is a very interesting feature of JavaScript that lets you have the same function instance shared among many object instances. And as long as you handle your disc value properly, they all work as designed. And so, if you wanna do like mixin, you don't have to do inheritance; you can just manually copy the function references over and they’re equal references to the same function. The function is not going to buy a prototype. CHUCK: Right. TIM: In a class spaced language, the class owns the methods -- they are statically bound to that class, whereas in JavaScript, it’s just a reference to some function; it doesn’t care how you get there. So inheritance is one way, copying the methods manually is another way and I showed in I think my object graph series where I have the same function called in four different ways. CHUCK: Hmm. I never really thought about doing that where you effectively just set the property on whatever object you are dealing with to be the function reference that you have stored off somewhere else under another name. JOE: So I wanna chime in here, just a little bit and say that as far as some of those techniques you are talking about, you know, copying functions and using prototypes; for a lot of the people out there that are doing the JavaScript but just barely getting into more and more complex JavaScript, I would definitely recommend that they shy away from writing it first because… that’s kind of tricky; but if you know what you are doing, it’s not such a big deal. CHUCK: Yeah. Is there a good explanation as to how prototypes work out there somewhere? JAMISON: There’s a bajillion of them. JOE: There's 80 crappy ones because it’s such a foreign concept. CHUCK: So Jamison, do you wanna recommend one or two of your bajillion… that isn't one of Joe’s crappy ones? JAMISON: [Laughs] Yehuda has a couple of good ones. I actually really liked Tim’s stuff on it too. There's one that gets posted all the time in JavaScript IRC channel that I don't have the link off hand. I'll grab a bunch of links and post them. They are all kind of a different… everyone kind of has a different way of explaining it, so it can be helpful to get different views on it to help you understand the concept. JOE: I think it’s one of those things that it’s just difficult to grok and you have to read like 4-5 different articles and do it a bunch of stuff before it really makes any sense. CHUCK: So you have to go make some mistakes before you really… JOE: Yeah, it’s a muscle memory type of skill. CHUCK: Yeah.   JOE: You can’t just read an article and then go out and do it. TIM: You have to practice it. JOE: Yeah, for sure. And I wanna chime in again that this is a lesson that’s true on the server side as it is on the client side and that is in general, reusing code, inheritance is not the approach you wanna take -- you wanna use aggregation not inheritance. There are exceptions to that, but the general rules should always be… like inheritance should be code smell. I think inheritance should absolutely be a code smell. CHUCK: [Laughs] TIM: There's definitely good uses for it; especially like if you are making UI widget framework; but if it’s just your reuse mechanism, it’s probably not. JOE: Yeah. AJ: So when you say ‘aggregate’, did you mean composite? Are way saying the same… JOE: Yeah, using another class. AJ: Yeah, I totally agree. Composition rules over inheritance -- what I've done mostly. CHUCK: So if I wanna compose a class or maybe just a set of functionality, what's the best way of doing that? I mean, we talked around it some but how do I add that functionality into what I already have? TIM: So you’ve done a lot of Ruby, right Chuck? CHUCK: Yeah. TIM: And how do they call it, mixins or modules? CHUCK: Yeah, mixin modules. TIM: So like you’ve got the enumerable thing and if you wanna pick class that’s enumerable, you just mix that in, you don't really inherit from it. CHUCK: Right. Exactly. TIM: So in JavaScript you can either mix it in by hand by copying all the properties or you can just embed it inside your object. I mean, it depends on what you are trying to reuse. That type of horizontal reuse where, instead of inheriting from it, where it is a relationship, it’s just has a, or needs this, or reuses this. CHUCK: Right. And that’s what I'm kind of driving at is what's the mechanism for getting all of that functionality. And there you said manually copy the references, but is there a better way of doing that? TIM: Yeah. Mainly copying will give you the Ruby-style mechanics where it’s sort of inherited. But the other method is just … the object inside your object -- compose it. CHUCK: Okay. So basically, you would have like your main object and then it would have a property in it just like enumerable functions or whatever. TIM: Yeah. Enumerable is not a good case for that. CHUCK: Right. I'm just throwing that out there in general; you know, whatever your module’s functions are, they live in kind of a property that’s its own object and then you just reference it that way. TIM: Yeah like in Node, I'm very often wrapping a stream and presenting them as a new stream. Sometimes I want to inherence the stream, but usually I don't; usually I just want to reference the stream inside my object, and my object another event emitter and then emit the events that I want in my abstraction level. So it’s a stream that contains a stream. CHUCK: Okay. JOE: Although personally, I find with the event emitter that is one that I do enjoy the inheritance. TIM: Right. But that’s more of a Ruby-style mixin where, I just want the ability of doing the event emitter. Like the event emitter constructor does nothing. It’s just methods that [inaudible] to your objects, it works. CHUCK: Right. TIM: It’s just inheritance is the easiest way to get that in your chain. CHUCK: Yeah. Is there a library out there that will do that sort of… JAMISON: Underscore has an extend function that I think just copies all the… CHUCK: Okay. JAMISON: …all the properties of the objects on to another object. JOE: jQuery has the same thing. And Node does have the utils that has that as well. JAMISON: And it’s not that much code to write if you don't wanna use any of those. CHUCK: Right. JOE: You can always copy 5,000 times in every program you have. CHUCK: [Laughs] TIM: And if you are at Ecma 6 you can just use object keys for each and it’s actually faster. JOE: Well now, we discussed this in the previous podcast – lodash -- you can get lodash and just build it with just that one function, right? TIM: Yeah! Yeah! CHUCK: [Laughs] JAMISON: I have no idea what… TIM: I think it’s a question of how much code is worth reusing; if it’s 5 lines, should you rather use that code or just write it yourself. CHUCK: Yeah. Well the other thing that comes in is at what point is code duplicated? Because sometimes you see that different pieces of code have a similar structure or doing some of the same work; but when it comes right down to it, I mean, sometimes you can consolidate that and generalize it. Sometimes you can’t. So how do you recognize it? How do you do that pattern matching? TIM: Lots of experience. I mean, that’s part of the art of programming is to know when to properly refactor your code and when it’s not a good idea. JAMISON: Yeah. Some of this comes down to the overhead in reusing other people’s code too. Like yesterday I wrote a function that turn underscore separated strings into camel case and that exist in the bajillion place. But do I really wanna have another dependency in my project to do something that’s so simple? AJ: Yes. JAMISON: No, I don't. CHUCK: [Chuckles] JOE: Well, yeah. This isn't the server side. Every one of those bytes does matter. AJ: But they don't because if you run it… well, they do and they don't, right? If you are on a big application, you are going to run it through the closure compiler or something of that nature and all of your dead code falls out; it just shakes the tree and boom. TIM: It’s not so much the code; it’s more of the overhead on the programmer. CHUCK: Yeah. In my experience, that’s generally more expensive than you know, a couple milliseconds in execution time. JAMISON: The overhead of having more code that you wrote yourself or the overhead of using someone else’s code? TIM:   Exactly. Which is more and that’s different. For every single use case. CHUCK: Yeah. TIM: Like, I don't really wanna Require-implement web sockets. I've done it once before; the spec changed five times since then I used someone else’s web socket library. CHUCK: Yeah, but then you look at what… sorry I got distracted. TIM : I was just going to say like, to me, it’s worth it. Like, I don't know how to set headers in the web socket library for Node, but I'm willing to mess around with that third-party code than re-implement the entire spec myself. Because in that particular use case, it saves me a lot of time. AJ : And in a lot of cases, I mean, can we like having our own code, right? You can go on GitHub; you can fork somebody’s project. If it’s been abandoned for six months, then you can pretty much just take it over and say, “Hey, I wanna refactor this. I wanna make it cleaner.” And they are going to be like, “Well, that’s great. Go ahead and do it,” you know? And then sometimes, they even actually want to help you on it, but a lot of times, you can just kind of you’ve got a foundation there. You're like, “Ah, this is kind of messy. I'll clean it up and make it mine.” TIM : I have a few of those you can take over. [Laughter] JOE : Well, finding duplicated code and eliminating it, you know, using somebody else’s code, somebody else’s library or writing on functions is just, one of the aspects of finding and eliminating duplicated code, I think the harder aspect by far is when we first start programming, we look for, “Oh, I've got the same five lines of code. I'll extract that out into a common function,” or something. TIM : Then you get Ruby where it’s one line per function. JOE: [Chuckles] CHUCK: Yeah, well if it’s verbatim, it’s easier to see. JOE: Yeah. The harder the thing is where we are using the same paradigm you know, we’re doing the same kind of task and just doing it slightly differently. TIM: Right. JOE: Patterns can come in to help. TIM: Headers help, but you don't want to overly generalize things because then they are no good for anyone. CHUCK: Right. AJ: I wanna piggyback on Tim's comment there. I’ve sometimes study started out and I'm like, “Oh yeah, I see I'm doing some things that are really similar over and over again,” so I'll generalize it and then I end up with this code that is too general and then I can’t use it because some requirements comes along that totally breaks it and the system doesn’t work. JAMISON: If you generalize until you just have made a time machine, you’ve gone too far. CHUCK: Well, one other thing that I've seen happen in code that I've written is that I'll see 2 or 3 examples that are doing more or less the same thing with maybe one variation, and so then as time goes on, after I generalized it, I have this simple case except I have this case statement or if, else, else  if, else if, else if, you know, to handle all of the different edges or the different specialized things that that one object needed. And you know, so sometimes it’s hard to find a good way of handling those different use cases just to get the same or similar pieces out. JOE: Right. TIM: Yeah. I was going to change the subject a little bit. Go ahead. JOE: Oh, I wanted to point out that there is one place where duplicated code -- I mean even verbatim duplicated code -- is not only acceptable, but often desirable and I don't know if any of you are going to guess what I'm going to say here… CHUCK: The one place -- hell? TIM: Unit test! JAMISON: Unit tests. TIM: School. CHUCK: School? [Laughter] TIM: You know, I have a story about that. [Laughter] TIM: I actually had a Computer Science lab teacher who failed me because I didn’t copy her example verbatim -- whereas mine compiled and hers didn’t. [Laughter] TIM: Sometimes verbatim is better even if it won’t compile. CHUCK: Depends on what the purpose is, right? TIM: Right. JAMISON: It sounds like a Harry Potter type experience. TIM: I switched schools after that. AJ: The worst thing I ever heard in school was I was talking to a co-student of mine and I was like, “So this should be done this way because this is how it’s done in the real world and this is a good way to do it.” And he's like, “Look dude, I don't care how to do it right or what makes it work better, I just wanna pass the test. So I'm going to do it this way.” That makes me like see it inside. JAMISON: I don't think that's the worst thing in the world; that just I means… I mean, if that’s what you are going for. TIM: What are your priorities? Do you wanna pass or do you wanna learn? JAMISON: Yeah. AJ: Yeah, that’s the thing is to me, coding is an art form, you know? It’s like code is my canvass and so when other people are like, “Ah, here is a stick figure; that’s good enough. It gets the job done.” I'm like, “Well, you go off and use PHP. But as for the other people that care…” TIM: Right. Craftsmanship, that’s one thing I love from the Ruby community; they focus on that a lot. I used to go to the Dallas Ruby Community a lot and I learned a lot from those guys. JOE: That’s why you TDD. CHUCK: Wouldn’t be Dallas Ruby Users Group will be D-R-U-G? [Laughter] TIM: DRUG? Oh what was their… oh, it’s just DallasRB. CHUCK: Oh, okay. Yeah, they started a Ruby group here in Utah in Salt Lake and they called it, The Downtown Ruby Users Group and they shortened it to DRUG. TIM: Nice. JOE: If you care about your code quality -- TDD. CHUCK: Yeah, absolutely. Oh, in fact on Ruby Rogues, we've just read, Growing Object Oriented Software Guided by Tests and they talk a lot about the testing stuff that we bring up. JOE: That’s a sweet book. CHUCK: Yeah and it really is and it really kind of gives you an idea of how your tests can help you organize your code. And there's way more there than we can actually go over on the show, but definitely, write your tests first; let them kind of guide your code and let them tell you when things are kind of getting too complicated or too hairy for you to deal with. Because if you can’t think about how to test it, then it’s probably something that you need to refactor. JAMISON: I don't know if we wanna get off those tangents. I have some things I don't understand about how to use TDD in the environment that I'm in though. TIM: I don't like TDD sometimes. JAMISON: We are doing lots of rapid prototyping and things change. I mean, I'm in a startup, so things change wildly from day to day, sometimes almost; so it doesn’t pay to invest that much effort upfront into good, clean code if you don't know if it’s going to exist tomorrow. CHUCK: Yeah, but if it does exist tomorrow, then where are you? JAMISON: Then you are left out but if doesn’t, then you wasted all that time. JOE: So, I have a little bit of experience with that Jamison and… JAMISON: You and I talked about this a lot. JOE: Yeah we talk about this a lot. That is really hard especially in the environment where you not 100% sure what you'll throw away, but prototyping without tests is definitely in my opinion a better way to go. But I always… once I know that the code is going to stay, the code is ready to go, I throw it away and rewrite it with test-driven development. And I'm actually right in the middle of publishing an article highlighting just like, I don't know, just like 80 lines of code that was written before and we just prototyped it out, how it worked when we were done after we test over it. And the difference in the code is just night and day for clarity -- night and day. TIM: So the take away is test driven if you want clean code .. prototype if you want code that solves a real problem. CHUCK: [Laughs] JAMISON: Ooh. AJ: I think there's still this idea of red/green refactor though. I mean like how do you know if your prototype code works, right? I guess there's lots of different definition of testing and generally, when we say TDD, we mean ‘unit testing’, but for me, I have to write tests for any API that I'm writing; I don't know if it works unless I'm writing a test, you know? So I write the code and that’s cool but it usually doesn’t work. JOE: I usually manually test it to verify that it works; it’s just a painful process. And it’s probably okay once, but if you have to manually test the same code twice, that’s usually your breaking point where it would have been better to write unit tests or functional tests. CHUCK: Yeah. JAMISON: I think Tim has something to say.  He's trying to break in. CHUCK: Go ahead Tim. JOE: But still, you know, writing tests for your code… or test driving your code for the tests is a lot like going dogging for the view. You know, you are missing out on the biggest benefit by far if you're only writing your tests first just so that you have tests -- that’s the secondary benefit of test driving your code. TIM: Right. So back when I went to DallasRB, the first meeting I went to, Dave Thomas was there giving out, Pragmatic Programmer Books and so, I was introduced very quickly to those kind of books. And one of my favorite ones is called, Interface-Oriented Design. I know who's read that, but the basic premise of the book is object-oriented programing is not what you want; interface-oriented programing is what you want. You can use objects if that's the way you do it but the key is when you break your code up in these different modules and you reuse modules, you have to stick to your interfaces. They have to agree on how they communicate with each other; how they are used, and then you can use whatever you want on the inside. CHUCK: Yeah. That’s a lot along the same lines as the, Growing Object-Oriented Software Guided by Tests book. They talk a lot about how the messaging between the objects that matters. You don't care as much.. well, you care obviously as a developer on how it gets the job done as you implement it, but ultimately, you wanna be able to send the message over there and not worry about how it’s going to do the job and just know that when you tell it to do something, it’s going to do it. TIM: Right. You just don't wanna get hung up on classes and inheritance and specific details of like one genre of OOP. CHUCK: Right. Especially since the interactions are the things that are going to effectively define how your system operates anyway. TIM: I mean, even TDD, that's focusing a lot on your API and using your API -- especially automated unit tests -- they are great for libraries where you know you want and you want to be rock solid, by all means, unit test the heck of it. I get 100% coverage. But if you are just exploring a space and you are trying to solve a real-world need, I mean that's the end result of all software; if it doesn’t solve a real world need, it’s worthless. CHUCK: Yeah. JOE: That's why exploring without tests is totally acceptable; just once you know the space well enough, you should have add in your code and go back and rewrite it using a test driven method. I've done that many times; we wrote HTML5 player for Pluralsight and it was… we were getting in a lot of spaces; we were doing stuff that we can’t find anybody else had tried to do. We've tried to use videos using the file system API which only Chrome and Webkit and Firefox support. AJ: All normal browsers? JOE: [Chuckles] We are all normal browsers but nobody but… we’d affect anybody talking about using video through the file system API. And so we were really doing some new territory and we just had to prototype without tests. But once we figured how the code is supposed to work, we threw it away and we rewrote it with tests. TIM: Yes. That's what I do as well. The bulk of my work is prototyping but once a library gets stable and people are actually using it, then I start worrying about unit tests and it usually helps me find a lot of bugs and clean up the API. JOE: Absolutely. CHUCK: Yup. All right. Well, were getting close to the time on picks. Is there anything else that you guys wanna talk over before we start sharing what we like? TIM: Did we wanna talk about like the JavaScript specifics of inheritance versus closures or save that for another day? CHUCK: We can over it briefly. We've talked about it before. TIM: Right. I mean, it often confuses people. CHUCK: Yeah. Why don't you just kind of give us a thumbnail sketch on how that stuff works? TIM: Well, the moment where I finally had the epiphany and understood it where was when I was writing the object graph series and I had to draw all these memory linkages together as diagrams. And I realized that a closure is an object. CHUCK: Yes. TIM: And you get a new instance of the object every single time you call the function and get your closure, whereas with prototype-based stuff, you get a new instance every time you use the new keyword. But otherwise, they are just a new syntax for the exact same thing. And as long as you are aware of this, it’s nice. The pros of the closure base is you don't have to worry about this. Everything is in your closure using the implicit nested scopes. CHUCK: Mh-hm. TIM: So its easer especially when you have callbacks all over the place. You don't have to bind your callbacks because they are pre-bound, but if you wanna have like 10,000 copies of the same object that are slightly different, you're probably better off using instances because they all share all their behavior -- they just have their own local copy state. CHUCK: Right. AJ: I have found that it’s fun to prototype with closures but when you want the code to get cleaned; using prototype is usually the way to go because they are problems with the organization and testing and memory usage with closures. TIM: Yeah. Closures hide everything secretly -- which can be good and bad. CHUCK: Right. Then it just comes back to what problem you are trying to solve. JAMISON: And I'm tired of all these ‘subjective’, ‘it depends on the problem’ thing. CHUCK: [Laughs] JAMISON: There's not going to be the right answer. CHUCK: Jamison, however you wanna do it, you are doing it wrong. TIM: [Laughs] JOE: If you have to ask, you'll never know. TIM: I wish schools had degrees that was the art of programming. I mean, Computer Science  is great; I love that field of math; but that’s not programming. CHUCK: [Laughs]  “I love that field of Math.” [Laughter] AJ: Amen. TIM: It is a field of Math, but I like it. It’s not programing – not at all. AJ: I hear ya. TIM: all right. Anyway. CHUCK: All right. Well let’s go ahead and get into the picks. AJ, do you wanna start us off? AJ: I absolutely do not. CHUCK: Jamison, what are your picks? [Chuckles] JAMISON: Let me pull them up here. I was not prepared. All right. So one of my picks, this is an old thing that lots of you probably already read, but it’s just The Pragmatic Programmer; just the original book. Lots of the advice is… it can seem fairly basic if you’ve done real world programing in a business environment, but some of it is still really great stuff. And if you are trying to get started and you don't have very much experience, then it’s all great stuff. I mean you should know everything in that book and some that you might know already but if you don't, you'll learn it and that’s great. So it was like $3 on the Kindle a couple of days ago and I picked it up. And then my other pick is just these course classes I've been going back through them because I didn’t really have time while they are going on, and going back to the natural language processing class especially and it’s so good. It’s definitely computer science not programming like Tim is talking about. But I think there's a lot of values in doing things that might not be practically useful just because they are awesome. So those are my picks. CHUCK: Awesome. Joe, what are your picks? JOE: So I have two picks; my first on is pair programing. A new place that I'm at… I just got this job at --- and so they haven’t done a lot of pair programming. I've been pair programming here and it’s just been really awesome and I think that people are finally starting to see the value of it – at least the people that I'm pairing with. My second pick is the game Farmageddon with an ‘F’. It’s was a Kickstarter and it was barely released and I haven’t actually played it yet, but I'm really excited to play. The game in my house I'm going to have a copy pretty soon. So that’s my second pick; Farmageddon. TIM: I've heard of that game. JAMISON: About pair program, do any of you guys do remote pairing, ever? JOE: Yeah. I've don't a ton. CHUCK: I've done a little. JAMISON: I should talk to you about that because I think it will be fun just to do that on just random side projects and stuff; not even for work, so… TIM: I have a tool for that. JAMISON: What's it called? TIM: I don't know – Cloud9 IDE. CHUCK: [Laughs] TIM: No, but seriously, we recently added a feature where you can collaborate in your IDE kind of like Google docs live editing. JAMISON: So it’s like Tmux, almost? TIM: Yeah but a little more graphical. JAMISON: [Chuckles] Yeah if you wanna click on stuff, I guess then that's better. TIM: Yeah. And I don't think we've integrated voice or anything. There's like an integrated chat and you can see each other’s cursors and it’s kind of cool. CHUCK: Nice. JAMISON: Can I have a new pick then? CHUCK: Okay. JAMISON: It’s called pairwith.me; it’s by a local guy name mike Moore and he's a Rubyist. He's a really cool guy. And it’s a little site for kind of hooking up with people that you want pair with and you can schedule time. It’s still like heavily in development, but if you just want to find someone to pair with, you are not like looking to pair with a specific person on a specific project, then it’s a cool little tool for that. CHUCK: Yeah. There are a few of them out there like that. JAMISON: Are there anyone that have one that are really popular? CHUCK: I don't think that there's like a big main one out there. JAMISON: You know, if GitHub added something like this, I think it would automatically win. CHUCK: Yeah. Probably. JAMISON: Sorry I totally butted in. CHUCK: No, it’s fine. Tim, what are your picks? TIM: All right. So I'm going to pick Interface-Oriented Design, since mentioned it. It’s a really good book and not too big. And also in case any of your listeners haven’t read them yet, I wrote three articles on how to Node about learning object through visual graphs and I had a ton of fun writing them and people so far have loved reading them. So it’s, Object Graphs 1-3; three articles on how to Node. CHUCK: Awesome. All right, AJ, are you ready? JAMISON: He fled in fear. CHUCK: [Laughs] He's going to make me do my picks next I guess. So, one pick… I'm not sure if it’s been picked not the show or not, but every time I use it, I'm always happy with it. And that is Amazon Prime and you can rent videos for free on it, you borrow books for free on it depending on whether or not they are available. And you can also get free two-day shipping, which I guess isn’t technically free since you pay the $80/year to get it. But anyway, I have already recouped $80 worth of value out of it. I am certain. So that’s one pick. And then the other one is just something that I've been using for a while here and it’s basically what I use to like edit contracts and things like that. I actually sign my contracts with it and stuff; it’s called PDF pen and it’s a PDF editor; it does OCR, it does a bunch of otherwise nice stuff. Makes it really easy to edit PDFs, so if you have to do any kind of PDF editing on any sort of  regular basis, then PDF pen is your friend and you can get that in the Mac Appstore. I don't know if it’s available for Windows. I do believe they also have a version for iPad. So if you are doing PDF stuff there you can do it there as well. All right, AJ what are your picks? AJ: I'm going to pick, Zola Gouda from Holland. JAMISON: Is that a pop band? CHUCK: Cheese? Am I right? AJ: Yeah it is a cheese. It’s a Gouda cheese and it’s pretty Gouda, you know? Sorry, that was a terrible pun, I know. CHUCK: I lived in Italy for 2 years and I'll tell you, good cheeses, Gouda was one of my favorites. AJ: So we have this grocery store here; I don't know if it’s outside of Utah, I'm not sure, but Harmon’s, is that anywhere else or is that just a Utah thing? TIM: Never heard of it. AJ: Okay. Well, Harmons is really nice because they have… they cater more towards the IT community and some of the organic stuff and then they have like a nice selection cheeses. And so I went there and they had a good cheese, so I just bought a chunk of it and I've been eating away at it and its good. And speaking of puns, so the other day we were having a meeting here and I said, “Well, I guess that wraps that up. Now back to your regularly scheduled programming.” I didn’t realize it was a pun at first, but then it was funny. CHUCK: Okay. [Chuckles] So is your pick that pun or puns in general? AJ: No. My pick is definitely not puns. I'm not a pun fan. I've had enough puns – oh, my goodness. I have too many friends that pun everything. So I'm not actually even picking that. It was just a story that I was reminded of. CHUCK: Okay. AJ: That’s all. CHUCK: Okay. All right. Well, we'll wrap the show up then. We'll all sign off. We'll catch you all next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.