The Ruby Freelancers Show 009 – The “Ruby” in Ruby Freelancers

Download MP3

Panel Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) Eric Davis (twitter github blog) Evan Light (twitter github blog) Jeff Schoolcraft (twitter github blog) Discussion Ruby Java .NET JavaScript Ruby on Rails Rescue Projects Redmine Chili Project Legacy Code Sinatra Rack Spree Ryan Bigg Radiant rails_admin Padrino Plugins attachment_fu Upgrading around customized plugins acts_as_commentable_with_threading Twitter API Facebook API Email LDAP authentication Single Signon authentication "Ruby is the glue that doesn't set" Facebook Connect ACH gateway OmniAuth Facebook Graph API Minitest Minitest-spec RSpec Cucumber Spinach Coulda "I want something like except it does ." Big Rewrites Nagios Picks Vagrant (Eric) Rookies in the Bike Shed by DHH (Eric) ActiveAdmin (Jeff) VeeWee (Jeff) The Power of Habit (Jeff) OO vs Functional Design (Evan) Pry (Evan) Mass Effect 3 (Evan) Scrivener (Chuck) (Chuck) Crafting Rails Applications (Chuck) RubyKoans (Eric)


EVAN: Are you on mute over there, Jeff? You are just damn quiet all the time. JEFF: No, I'm seething. CHUCK: Seething? EVAN: Oh, cool. Let your hate flow through you. Strike goes down with all of your--- CHUCK: [Chuckles] ERIC: I don’t know that Start Wars reference. JEFF: What leads to hatred or what does hatred lead to? EVAN:"Fear leads to anger; anger leads to hate; hate leads to suffering." JEFF: There we go.  [This podcast is sponsored by Harvest. I use them for tracking work and invoicing clients. You can get a 30-day trial at Use the offer code “RR” after your 30-day trial to get 50% off your first one.] CHUCK: Hey everybody, and welcome to Episode 9 of the Ruby Freelancers Show. This week on our panel, we have Eric Davis. ERIC: Hello. CHUCK: We also have Evan Light. EVAN: I'm here to talk about Star Wars, as usual. CHUCK: [Chuckles] “May the force be with you. Always.” We also have Jeff Schoolcraft. JEFF: What's up. CHUCK: And I'm Charles Max Wood from This week, we are going to be talking about the “Ruby” in Ruby Freelancing. I think last week, we did mention that we were going to talk about Accounting and Handling Books. I'm trying to get my CPA to come on, and I couldn’t get it lined up to this week, so we are going to keep trying. So real quick, I'm just going to read the explanation on here, and we can see what folks said. It says, “The podcast is mostly about freelancing and very little about Ruby. I think the Ruby side is worth some discussion. For example, I’d like to hear what types of projects you are working on as freelancers, what frameworks you are using on Rails; if you are building stand-alone apps or adding features to existing apps, what kinds of features do clients ask. And in general, whether code written by you as freelancers is different than if you are full timers for the same clients. I know you talked about it a little in the first episode or the second, but I think it's worth elaborating.” And then there's a comment from Eric Davis that says, “Good idea.” I'm like, “Oh, there's one comment.” Alright, so let’s kind of talk about the first part for a minute. Are we in Ruby freelancing kind of by default, or is there a reason that you guys work in Ruby in particular? EVAN: Because I hate Java. I mean, seriously, I ran to Ruby because I loved Ruby after hating Java. It's just that easy. I hate Java. Please let me do Ruby. JEFF: Mine is not so much hate .NET, but loved Ruby so much more than I thought. EVAN: Oh well, fine. Wait, I'm confused now. Jeff, you are being positive. Don’t do that. JEFF: Sorry. But I was freelancing before the language choice, so it just sort of happened that way. But if I change again, I may still not be freelancing; it will just be my language choice that drives the projects that I'm interested in. EVAN: In fairness, I went with Ruby because I really do love Ruby. But just wanted to get that out there. CHUCK: Right. What about you, Eric? Is it kind of just because that’s what RedMine is in, or did you kind of transition in to it? ERIC: I'm a bit different. I've actually been doing Ruby and Rails for a while, and then I've actually freelanced for PHP projects for a while, while doing projects for the clients. And then recently, I've been doing a lot of JavaScript. So for me, it's just more along the lines of like, Ruby and for the most part, Rails is the best backend language framework for me, but I'm actually flexible and will work with whatever the project needs. EVAN: We are talking about Ruby here. ERIC: [Chuckles] But I mean like, if the code base already has a bunch of PHP or it's a full JavaScript app, like you are not going to try to force Ruby into it. So for me, it's more along the lines of, “If I can help this client and I have skills they can use, then I'll use whatever skills I have for it.” Ruby is kind of my best choice, but I have other choices if they don’t wanna use Ruby for some reason. EVAN: That's probably fairly true for most of us too. CHUCK: So it's kind of like what Kent Beck said, “I'm partial to the languages I get paid for.” ERIC: [Chuckles] Yeah. EVAN: Well, right tools for the right job too. Ruby is not necessarily always the best thing – but it's most fun. CHUCK: Yup. So I kind of got into Ruby just because I felt like that’s where I had the most… between all of my different websites and things, when I went freelance, I had the most exposure there, and so it's easier to find clients there than anywhere else. But I don’t have the depth of like, “Well, I came from Java or .NET or PHP or some other language  or framework,” and can say, “Yeah, so I'm here because I really love it more than those other things.” I mean, I did do some Java, some C++, and C in college, and I've been picking up JavaScript, but I don’t know. The funny thing was that in Java and C++, I enjoyed programming, but they didn’t compel me enough to actually want to do it for a living. And I got into Rails while I was actually managing a tech support department. And that was what really got me to the point where it's like, “Oh, this is what I wanna do.” So it's not totally by default that I do Ruby or Rails, but anyway. So the other question is, are you using frameworks other than Rails? Or just Rails? How do you decide which technologies you use for your clients? EVAN: It's usually, “What is language that the rescue project already written in when I get there.” CHUCK: [Chuckles] EVAN: So that was part of the question too is what kinds of projects do we work on? Atleast for myself, a lot of them maybe 2/3 of them are rescue projects in one form or another. And they are written in Rails either by another contractor, not that we know all the time pretty much, whose done a kind of … job and so they call me into clean things up. Yeah, otherwise, other work than cleanup work. But the cleanup work is the fun one to complain about. ERIC: Yeah and for me, I mean most of my stuff is Rails. I’d say 80-90% of my work is RedMine or ChiliProject, but it's kind of unique in that they are greenfield things for client, like the project’s greenfield one meaning it's all new, but it's usually plugin, so I have to integrate this all new code base to into 40,000-50,000 lines of legacy code. So I have this combination of, I can use new stuff and I don’t have a lot of stuff I need to deal with in my code, but there's like a ton of integration points that’s all like C. I think some of that I think are pre-Rails 1 days. Code that’s still in production. So I mean, to kind of get back, it's mostly Rails for me. I've done Sinatra, I think I've done a little bit of just plain rack stuff, but 90% is Rails. CHUCK: Right. All of my projects are far have been Rails. I've done a little bit with Spree, which it's kind of a framework all into itself that hooks into Rails. But yeah, most of them has been Rails, and most of them has been... EVAN: Spree, that was the source of pain for me a couple of years ago. CHUCK: Yeah, it's gotten better, but still… EVAN: I know it's an engine now. Ryan Bigg’s talked about it a little bit. I don’t know about you Chuck, but when I used it, it wasn’t an engine; it was an app that you extended in a really unusual and convoluted ways. CHUCK: Yeah, two things on that when I was working on it, one was that it was a highly customized Spree, so somebody had gone in and basically monkey patched over the top of stuff, and made it really, really painful to code against, because they had no clue what they were doing. This was pretty much my first project after I got laid off, so yeah… EVAN: Oh, so this was when it wasn’t still an engine yet then, probably. CHUCK: No, it wasn’t. EVAN: Well back then, there really weren’t too many good ways to extend Spree. [Chuckles] CHUCK: Right. EVAN: Monkey patching wasn’t entirely uncommon. I'm just saying from my memory of it. CHUCK: But any more, I mean. I've been on a project where I probably have to use Spree, but it looks like it's just an engine and you just, yeah, you can customize some of the stuff, but most of it just works the way you want. It really looks like it's come a long way and actually makes sense to use now. ERIC: Not to get too far off a tangent, but a few of the open source apps like Spree, RedMine, Radiant, a few other ones, they kept basically reinventing the wheel of how to do not Rails plugins, but plugins like, “This is something modular you can install to the app.” RedMine, because back then I was working on RedMine when ChiliProject wasn’t around, like the side of like, “We are going to use engines,” like the classical Rails 2 versions of engines. And it's funny because overtime, I noticed Spree and Radiant and everyone else who built their own thing ended up doing all the features of engines, or actually like moving to engines. And then finally when Rails 3 come out, that was like engines are what you should be doing. But it's kind of sad because back in that day, like everyone had their own thing, everyone had their own API documentation, and now it's fine; you just build this mini Rails app as an engine, and that’s what you need to do to extend it. CHUCK: So one thing that that reminds me of with the engines is I had one client come to me and say, “I want this site, I kind of built the frontend for,” and then she’s like, “I'll just manage it with RailsAdmin,” which is an engine you stick on the backend, and basically it's just interface to your database. And it made sense for her, because she was a PHP developer. But I was sub-contracting to her for another client, and that client, I was just sitting there going, “How is this client ever going to figure out what this is?” because it's very database-oriented. It's not an interface for the client themselves to really be able to do a whole lot with. And you try and explain these stuff to them, but you know, but if they are on a tight budgetary constraints or something, it's just like, “Look, it's cheap. It works.” But you know. EVAN: Yeah, Rails_admin is nice I guess when the tables are somehow comprehensible to non-developers; when they are named well and their contents makes sense, but as soon as you start throwing join tables in there and what not, and that’s almost any app really, then they'll are probably going to get in trouble if they don’t understand data bases at all. Yeah, I heart Rails_admin, CHUCK: Yeah, it's really nice if you understand what's going on there, it does make it a whole  lot simpler than going in and trying to manage it all through the command line or something. EVAN: I really wanna hear about the kinds of projects that Jeff has been working on lately. JEFF: I’m on the same camp that Evan does. I have a lot of rescue-ish type projects. And even ones that aren’t rescue, I mean they are still fairly established app that I mean you are just adding to. I can't tell you the last time I’ve had a completely Greenfield app for anybody. I mean, other than myself. So it's mostly Rails stuff. Sometimes straight Ruby stuff, and then occasionally there will be a Sinatra app or Padrino app thrown into the mix. But 9 times out of 10, it's all Rails to me and older Rails too. I guess they are trying to figure out how to configure… CHUCK: [Chuckles] Yeah. When you get a 2.0.2 or even a 2.3 application, do you guys usually wind up recommending to them that they upgrade to the latest version or do you just work with it? JEFF: I almost never recommend to upgrade. I came from a different place than a lot of people. And once you spend money to have people do work for you, then it's easier to see the other side of things. I mean, it's really hard to recommend an upgrade for upgrade’s sake. Now, I mean if there is security vulnerability and you have to go from 2.3.10 to 2.3.14, then yeah, you suck it up and you probably do it and it probably takes an hour. But I mean, to go from 2.0.2 to anything is ridiculous. But to even go to like 2.3.5 to a 3.0.0, if it's not well-tested and well covered, it's going to be a nightmare. I mean, you got to go to 2.3.8 or so to get… 2.3.14 to 2.3.18 whatever the latest is to get bundler, and go to 3.0 and routes change and a bunch of stuff changes for 3.0 and  3.1 is assets and 3.2 is more changes. So it's really hard. I mean, I'm actually discouraging a client from upgrading their responses… well, can we just throw money at it, and then see where we can get. I mean¸ they are fairly well-covered, but I don’t think it's an instant win for them. Plus they are using older app like 3-4 years old, so they are using way old plugins, which is an interesting problem for upgrading -- especially when you are talking about like attachment foo, that was hacked.  Like they were hacking on it to make it work for their site. And so you'd have to stick with that, and try to make it work; gemify it so you can go to Rails 3 or do something crazy like try to shoehorn it into Paperclip or Dragonfly or whatever. And 9 times out of 10, I won’t recommend. I mean obviously it varies for everything but yeah, I try not to upgrade for upgrade’s sake. It will certainly be nice to do, but it's really hard to justify spending people’s money for that. CHUCK: So it's interesting that you guys bring up the rescue projects, and Eric’s been adding features more or less through engines or what have you through RedMine or Chili Project. Most of the project that I've worked for the last year and a half or so have almost all been with like 2 exceptions. There have been greenfield projects where somebody’s like, “I have this brilliant idea and I need it built, and I will throw lots of money at you, and you'll make me happy.” [Chuckles] EVAN: I think I've only had two or three of those in the past two years… my current client now, and one I had a have few years ago. CHUCK: Yeah, it's funny too because most of the ones that I built over the last little while have all been social networks of one type or another. And so it's… EVAN: What color is your social network? CHUCK: The one that I've been working on most recently is Pink. [Chuckles] EVAN: [Chuckles] CHUCK: And then I’ve built a yellow one, and a blue one. It's really interesting to me that there is so many of them. But they are all focused around some niche or some idea, and that’s what they want. And some of them have really some interesting aspects to them, but I'm always pushing my clients a little bit, saying, “Look, how are you going to support this? How are you going to make money with this?” EVAN: Okay, so that gets into the other questions in this topic was what kinds of features do your clients ask for? My first response was, “Features that they probably don’t need.” CHUCK: Yes. EVAN: Yeah, that got a laugh out of everyone. But when I said that, I caveated it with, “And yet, we are all experts on this because we all run multi-million dollar startups. And that’s why we are freelancers; clearly, we know exactly what the businesses need.” CHUCK: Right. [Chuckles] Yeah. Well, the thing is I don’t think I've worked for any of these clients that actually have venture funding of any kind. They are all like, “Yeah, I've saved up a whole bunch of money, and so I need to get it out the door within a certain amount of time or under a certain budget.” One of my clients, he actually had another business that actually brought in enough money for him to support and employ me for almost a year, working on his application. So yeah, it's kind of interesting that way. And one of my other clients, he basically kept us pretty limited to a certain of numbers of hours every week and things like that to manage his budget. So it really depends on the situation, but yeah, none of them have these ideas that are really strongly vetted by the venture capital community or anything. I mean, they are all, “I'm the sky and I wanna build something that does this, for this community or this group or people with this kind of interest.” EVAN: Pretty much everything I've worked on, at least for the past two years, except for one customer, I only had for a week or two weeks, I mentioned once upon a time. Other than that, they’ve all been VC-funded. Lots of startups. CHUCK: Well, I wonder what we were doing differently to attract different types of people. EVAN: We talked about this in the conference podcast. I deal with a lot of my networking -- I guess, marketing if you will -- through Ruby d-camp or through going to conferences, and the people I meet there either work for startups, or work where no people who work with startups. So in direct marketing, I have a lot of contact with startups. CHUCK: Great, that makes sense. And yeah, my latest client is actually a fairly large company that’s based out here in the west. I mean, it does vary, but yeah, it seems like over the last year, most of my clients have been the guy with the idea and money to throw at it. EVAN: Although oddly, my latest client is not a startup. It's actually state government, and they found me through a gem that I wrote kind of on… CHUCK: Which one is that? EVAN: It loads a gem, [unintelligible] with threading, which was something I threw together… when I was a startup employee, I threw together for a project so that way we could have threaded comments rather than just chronologically listed comments. And really all it was is just a mash up of [unintelligible] with awesomeness, because when they saw it, they thought, “Hey, this could be like peanut butter and chocolate.” And it turns out that it  kind of was. And the funny thing was I built it and the project I was working on got canned, and so I never used it. And of all the gems I put out or all the tools I put out, it's what people use the most is the one I've never used. CHUCK: Right. So I kind of wanna get into one other thing, because it just occurred to me I was looking at this explanation of what this person wants hear about. It says, “If you are building standalone apps…” they wanted to know if you are building standalone apps and adding features to existing apps, one thing that occurs to me is a lot of times, when we wind up integrating with other systems like Twitter or Facebook or whatever. How often do you find yourselves connecting to stuff like that. ERIC: Very, very little. I mean, we do email mostly, but that's in the app. And then I think I’ve done with the twitter API. Mostly just pulling some data out of it, but most of my stuff is like line a business, back offers, does it need the social features to get work done. So most of it is all internal code. And a lot of the times, my clients, their installs were way behind a firewall, so I couldn’t get out of it even if I wanted to. JEFF: My experience is pretty much like Eric’s I reach out to other services occasionally for authentication. And I have one client that’s pushing stuff to Twitter, both as a client and then as messages to their own Twitter account. I've done most of that stuff for my own projects, than I have for client work. ERIC: Real quick, now that I think about it: I have done some external stuff, but that’s LDAP authentication, and then single sign-on authentication. So it's still internal, but it's hitting another internal server. EVAN: Yeah, with the projects I've worked on, almost every projects that I worked on some kind of third party integration. [unintelligible] said that Ruby is the glue that doesn’t set. So always some kind of integration work, but I've never actually had to specifically integrate with Twitter. I had to deal with Facebook connect. Hated it. CHUCK: [Chuckles] EVAN: Really. Let me tell you how I feel. That everything else I've integrated against has been usually more obscure things, like I’ve had to integrate against an automated clearing house gateway, ACH gateway for looting money around -- and that was hell. I mean, really seven different kinds of it. And then other simpler and/or custom APIs for small services that I can't remember off the top of my head. CHUCK: Yeah. I've done stuff with Twitter and Facebook. I've also set things up with Omniauth so that people can just sign up with. EVAN: Omniauth is wonderful. Thank you, Michael Bleigh. CHUCK: In fact, one of my clients, if you wanna use his apps, you have to sign in with Facebook. And then it uses the… what's the new API? The JSON-based API? EVAN: I don’t know. I haven’t touched Facebook since Facebook connect made me ill. JEFF: What are we talking about, Graph? CHUCK: Yeah, the Graph API. So yeah, it uses the Graph API to pull information and stuff. JEFF: Yeah, one other clients I have, they are doing strictly Facebook Auth for now. What they wanna do is strictly Facebook auth, eventually open it up to Twitter and LinkedIn. And part of that has just been to tone down spammers, so it's easier than trying to deal with spammers on your own. Facebook do it because they’ve got a lot more money to do it, and so sure, people gain the system in Facebook, but it's going to take a lot longer for them to gain the system and come back and then authenticate with us and create an account. So that’s been one of the reasons we're doing it, but some of it is a nightmare. EVAN: Deal with Facebook, yay! JEFF: Some really, really esoteric cases and it's likely not Facebook’s fault; it's likely this code. CHUCK: [Chuckles] JEFF: I tweet about it. It makes me wanna stab your eyes out. Twice, just to make sure you got it right the first time. EVAN: Is that both eyes or just the same eyes twice? JEFF: Both eyes, twice. EVAN: [Chuckles] ERIC: It kind of sounds like [unintelligible] JEFF: Four separate stabbings. EVAN: Yeah, you should be stabbing three times not three times each too, right? JEFF: But yeah, I mean that stuff, authentication is an interesting beast but… we use Omniauth – the  original OmniAuth -- like the 3.2 OmniAuth not upgraded to 1.0, but the process is just so convoluted. Not OmniAuth’s process – our process -- but… EVAN: Yeah you know, now that you mentioned it, the few times I have dealt with OAuth in client applications, they always end up with some weird convolution because of something specific to the client app. When I use OmniAuth, when I’ve done OAuth just some little app that I own, it's always really simple client apps. There's always something strange that the client wants to do, that makes OAuth painful. CHUCK: So I'm also curious about testing. I'm assuming you guys all test your code? ERIC: Yeah, boot up Firefox and just click through for a few minutes. [Laughter] EVAN: Woohoo! Actually, I use mapper... I basically formed the workout to all bunch of people overseas, and I have them split them up amongst themselves and they click through. CHUCK: Oh there you go, mechanical… EVAN: [Chuckles] CHUCK: So do you ever have clients come to you and say, “We don’t want it tested?” JEFF: Yes. And I don’t think I've ever had anybody explicitly say they don’t wanna spend time on tests, but I mean, this is a classic bad example project, I guess. It's the one that stabs your eyes out a couple of times with. CHUCK: [Chuckles] JEFF: There's like 70,000 lines of code and like 500 lines of test code. And if you get rid of the scaffold test code, it's probably two lines that don’t work anymore. CHUCK: [Chuckles] JEFF: And so… EVAN: Oh! I had a client like that. Go ahead. JEFF: So the classic issue is, “Well, we need to upgrade this authentication stuff because we are having problems with Facebook.” And for these three people, out of 16,000, they can't login, so we need to upgrade. It's like yeah, that would be great if they had any tests, but we don’t. And this process is not as simple as go over to Facebook, sign and come back and we are good. It's come back and we'll go through 20 different paths, and maybe you are good, and maybe you are not, and you are one of those three people. So I tried to explain this to the client, said “Yeah, I’d love to do some upgrades. I’d love to work on some of these code. I'm writing tests around my stuff that I'm doing, but we sort of need full end-to-end integration level features or specs to see that this stuff actually works. And some off handed flipping comment, “You mean you don’t do that already?!” It's like, I can't reach through phones and slap people because… [Laughter] Sometimes I wish I could. So in addition to having not done this already, which I don’t know. We'll not talk about clients today. But yeah… [Laughter] EVAN: [unintelligible] I feel like we enabled you here. JEFF: I don’t need enabling, believe me. I've got every filter at my disposal, locked down, trying to keep me from throwing myself down the pit of hate. CHUCK: [Laughs] ERIC: For the listeners, if you ever see Jeff in a conference and you can get him to have a drink with you, you'll probably get some crazy stories out of him. JEFF: See that’s the thing: I don’t drink. And it's because I'm afraid of who I'll be if I do drink. CHUCK: [Laughs] ERIC: [Unintelligible] the FBI will probably come and arrest you for all the NDAs you broke. JEFF: [Chuckles] Maybe that. Maybe I would just be cute and cuddly and a funny guy, but I think I would be a ranging ball of hate and fury -- and I will go to jail. So that’s why I don’t drink. EVAN: Let’s see, if you smoke pot, you would probably be the latter. If you drink, the odds are at favor, your being the former. CHUCK: [Laughs] EVAN: Alright, I'm not picking on Jeff; I'm picking on alcohol. And no, I've never actually done pot. I’ve just read an awful lot about these stuff. CHUCK: I'm a little curious then, what tools do you guys use for testing? EVAN: Whatever the clients saddles me with is usually the first answer. I like sameness, I was going to say “homogeneity”, but that kind of hurt my tongue. So I just said it anyway. I don’t like trying to change code bases over the Minitest, but that’s what I would use on everything. If it were up to me, I’d use Minitest spec. But a lot of people use some flavor of rspec, heaven help them; a few people even use Cucumber. But whatever is there is pretty much what I use. JEFF: This all goes back to I never had greenfield project, and neither did Evan, so it's whatever you get settled with, basically. I mean, most of the clients that I worked with, I've fallen to rspec camp. I don’t know if I'm selecting all the test unit folks out or what, but most of them are rspec. I have a few that used cucumber. I have some that try Acceptance and Rspec Acceptance test, and Rspec Request Specs. I've tried that some and to be honest, I would rather go back to cucumber than mess with request specs and acceptance specs and rspec. EVAN: If I have to [unintelligible], I would try to introduce Spinach instead of Cucumber. Jesus, you can call by regular expression is the root of all evil. CHUCK: [Chuckles] JEFF: No way, Spinach is a real thing? EVAN: Yup. It is. If spinach is a real gem, that is still tied to Gherkin a little bit. Basically just takes Gherkin, then generates essentially a scaffold for your tests, which by the way looks almost exactly like this thing called Coulda, which looks almost exactly like called Rspec Story Runner from back in the day. And then you just fill your test devs into these little blocks that map directly to these… so there's none of that regular expression crap in there. And it's just code instead of … okay, I'm going to stop now. CHUCK: [Chuckles] EVAN: Chuck’s heard me go on about it this before. I'm going to stop now. CHUCK: Just a little. [Chuckles] Yeah, for those of you who don’t know: Evan wrote Coulda. EVAN: Yeah, it's okay. No one uses it. CHUCK: Oh, I'm sure somebody uses it. EVAN: Yeah, five people out there, thank you very much five people. CHUCK: The other thing I'm wondering about is so we mentioned that atleast for my part, I get a lot of social network type jobs, like, “I want something like Twitter, except that it does this.” “I want something like Facebook except it does this.” What other types of projects do you guys typically see, as far as functionality or whatever goes. We can include Eric on this. I'm a little curious to see what kind of plugins people are asking you for. EVAN: You totally nailed it, man. Most of clients have been, “I want something like Facebook, but this.” JEFF: There's one time I've had a client tried to deal with social network, and that’s it. I mean, I don’t think everybody has ever asked me to do a social network. I don’t think I’d ever help somebody do a social network. EVAN: [Laughs] JEFF: I mean, 90% of the stuff I do -- let’s say 70% of the stuff I do -- is boring, internal-only type apps for a very small section of people. I've worked with big pharma companies, or I’ve worked with people that worked with big pharma companies. So to manage all the doctors, they used to pimp their jugs, basically. There’s a site for that, and I helped some drug companies. I helped build that. I've done a bunch of dashboards so you can see -- one of those was for insurance companies -- you could see the sales basically how the sales aggregated through down lines, so it's the pyramid scheme. So, you sell and then you have agents under you that sell you can roll all that up and you can see how they are doing. I mean all bunch of one-off stuff and not… I don’t know if I can get into details about naming all the specific products I've worked on. EVAN: In fairness, I can say I've done a lot of social networks, but some of them may have very pretty far from standard social network, but it just seems inevitable. Almost every clients wants, “I want to be able to follow, I want users to be able to follow each other. I want them to be able to like things. I want them to be able to comment on things.” And invariably, there's that huge Facebook flavor that gets associated with all of that. And the part that really gets me frustrated personally is how they end up with products that in some way or another, resemble Facebook -- which doesn’t feel to me like a recipe for success. It feels like… CHUCK: [Chuckles] EVAN: I mean really, you succeed by being different. If you are just imitating someone else who’s successful, it starts to feel like cargo culting. CHUCK: So one other question this leads me in to then is let’s say you have the client that comes to you and says, “I want a Twitter clone.” Like down to the last feature. Do you tell them, “No”? Do you try and talk them out of it? JEFF: Yeah. EVAN: Yes. JEFF: Or I help them write a Craigslist ad. [Laughter] EVAN: I've actually had one lead like that before, and I took the requirements apart, talked to the client and said, “You realize xyz is exactly like Twitter or exactly like Facebook. Don’t you wanna be different?” CHUCK: Yeah. The first client, he came to me and he said, “Yeah, I want you to build me a Twitter clone.” And yeah, I almost laughed at him, but I looked at him and I said, “You realize that you have a couple of problems.” And he’s like, “Really? What are those?” Yeah, the first thing I said was, “Well, Twitter is not making money.” And I'm still not sure if they are or not, but if they are now, they weren’t then. Then I started explaining, “Okay, look. Here are some of the other issues here.” And so he started talking to me about the niche that he wanted the site for, and what in particular, he wanted to accomplish and then we kind of came up with unique selling proposition. And it turned out that he had a much better idea of what he wanted than he initially pitched me on. EVAN: I've had those clients too where what they tell me initially that they want is really not what they want, and I don’t find out what it is until we get into a discovery process. I pull lots of teeth, metaphorically speaking. And then sometimes, they don’t necessarily want an x clone; they actually want these features and they can be very different. CHUCK: I think we have a responsibility to our clients to do that kind of thing, the pulling teeth. Basically saying, “Look, in order for me to most effectively provide you the value…” because I mean that’s the whole point, right?” EVAN: Right. It's part of the communicating. If they tell you they want a Twitter clone, and that’s the extent of the communication, you'll build them a Twitter clone, then they'll probably say, “Well, that's not the Twitter clone I wanted.” So it's part of the so-called “Agile process” of basically which is just called talk to your client frequently and understand them. Yeah, I'm totally with you. CHUCK: Yeah, and I went through this with my newest client, who I'm actually kind of in the middle of a rush job. I mean, I'm doing the podcast because I feel like I owe it to the audience, and I'm also doing it because I go fearing insane if I had to write any more code before today. So anyway, so went through this whole process and I mean we were on this totally rush time crunch deal where we have to get things done by Monday. And it really benefited him because the first night that I “got to work”, I sat down and I hammered out some of the features that I knew were going to be in there, but he went through and he revamped like half of the process, because I started asking him questions and he realized that some of the stuff didn’t line up properly. And so, we really do need to do that kind of stuff for our clients, so that they get what they need out of it, so we can do the best job for them that we can. EVAN: Well the flipside, my latest client, they were misfortunately very different from some other things I've done. They want a learning management system. And so I was digging around a little bit because they had some specific requirements for what they wanted out of them. And they were talking about basically building something from the ground up. And then looking around, there are several, which some are open source and have really licenses on them, that they could either potentially try to participate in or they could fork and add to. So I said, “Hey guys, if you wanna build something from scratch, maybe you wanna start here.” Because when I came along, they were talking about essentially building something from scratch. CHUCK: Yeah, I've done that too. JEFF: This is what I don’t understand, I mean Twitter, can't you push them to yammer and have them or one of the 50 Twitter clones that are on GitHub? I mean, and the social networks, I mean, I know there's a lot of customization but I mean, I don’t know… CHUCK: It depends. In this particular case, the only thing he really wanted was the kind of the short update that you can get from twitter and some of the following features. And then there were a whole slew of other features. I'm going to get a little less general, and I'm going to get about as close to the NDA or handshake on, “I won’t tell them what I'm building for you,” or whatever and just mention that this is a fitness app. So there are a lot of features that are related to that that he wanted in there that didn’t necessarily fall under a Twitter clone. And so that handful of features, in order for me to modify somebody else’s code, versus just building it myself probably wouldn’t been … either way. Just figuring out what these other folks had done with that app. And so I just hammered it together myself. EVAN: For my clients, by the time I get there, they already had a ton of code that they wrote themselves, so it's too late to bring in something else. CHUCK: Right. So you do the big rewrites? EVAN: No, I almost never, ever have to do big rewrites. It's always, “How can we make what you have work better?” CHUCK: I guess that’s what I meant was just that you  rewrite one section at a time and rework one section at a time, so that it does what they need. EVAN: Pretty much.  Yeah, I'm definitely in favor of big rewrites. I've done enough big rewrites even in a government days where it's so obvious that they are going to fail. Because if you don’t have  all the features documented clearly somewhere, then what you are really doing in rewrite is reverse engineering effort of your own product or the client’s product. And unless they’ve memorized every little feature and they can jot them down for you, you are invariably going to miss some -- and you'll end up with an unhappy client. CHUCK: Alright, well we need to get in to the picks because I need to start wrapping this up, because I’ve got to get ready for another podcast in about an hour. Eric, why don’t you go ahead and share your picks with us? ERIC: So I got two today: first one is Vagrant. It's at if you haven’t heard of it, it's basically a Ruby gem that manages Virtualbox virtual machines, so you get to create a file that says, “I want three virtual machines, each has a 1GB of RAM, one is going to be called this, one is going to be called that.” And then you run a command and Vagrant will actually install the virtual machines, booth them up, and you can basically SSH in. I found it really, really useful for doing like dev ops type stuff, like if I'm trying to set up a new server, I can actually build a virtual machine or actually hold virtual network. Practice a setup, figure out how to code it up in Puppet. And then once it's all good, I actually push that to my main servers. It's also really good, like I had to do some WordPress development for one of the products I'm working on, and instead of installing Apache, installing PHP, installing MySQL and all that stuff in my laptop, I made a virtual machine, installed it on the virtual machine, did my work on a virtual machine and then when I was done, shut it down. And so I didn’t actually have these conflicting configurations on my laptop. And this is good if you are doing like PostgreSQL, if you have like one app uses PostgreSQL 9, but another app uses PostgreSQL 8, it's kind of hard to balance like which ones are installed. You are going to virtual machines and keep them separated. So Vagrant is the easiest way I found for that. It's not really that good for like production stuff I don’t think, but for like development and hacking on things, it's really great. And then my second pick is a post by DHH. It's called Rookies in a Bike Shed. If you've ever worked on open source or maintained it or any of that stuff, it's something you have to read. It's basically he talks about bike shedding and about how bad it is. And I'm basically one of the lead developers core of whatever thing of ChiliProject, and I was working in RedMine for years, and I could probably say with good certainty, 50% of my time in open source is shutting down bike sheds. And it sucks, especially if I wanna actually do code, I spend more time managing than actually doing coding now. So it's a good read. I kind of start linking to this whenever people start a bike shed, I'm going to say, “Hey, go read this post and then come back to this discussion and see what you have to contribute later.” CHUCK: Nice. Jeff, what are your picks? JEFF: I guess ActiveAdmin would be my pick. I know there's been a lot of love for Rails admin. I'm not a fan of… EVAN: +1 on ActiveAdmin. JEFF: so I guess the big difference is that Rails admin tries to scaffold everything for you out of the box and give you a CRUD interface for all your models. And if I didn’t say Rails admin, that’s what Rails admin does. Active admin goes the other way; it doesn’t do anything out of the box, you have to do it all, but it's dead simple to get crud stuff up and running, and you can still customize it fairly easily. And so before ActiveAdmin, I was using Typus, which was… it's another admin. It has some generators and some config files. It manage permissions and attributes and stuff like that. And it was really good and I moved to ActiveAdmin because it was prettier, and I ended up liking ActiveAdmin. So that’s the first one. Vagrant is a good pick. I'll agree with Eric. There's another project out there called VeeWee, which helps you build Vagrant boxes and share them with your team. You have a team, if You work with other people, so… EVAN: [Chuckles] wait, you don’t do that. JEFF: Sometimes I do. CHUCK: People suck. EVAN: Whoa, whoa, whoa. Chuck, are you channeling Jeff? CHUCK: [Chuckles] Don’t people really suck? EVAN: [Chuckles] JEFF: Those are my two big ones. The third one is a book I'm reading… now I have to find the name of it. Something about habits. CHUCK: 7 Habits of Highly Effective People? JEFF: No. ERIC: Now Habit or whatever? JEFF: I don’t know. I'll find it. It's some new book that’s got a yellow cover. It's about the habit cycle. The cue, action, reward. Amy Hoy talked about it, and it hit some of the blogs I've read a couple of weeks ago and I finally got around to reading it. It's been a good read so far. I mean, I don’t have the quotes, so I'm not going to mention it. ERIC: It's The Power of Habit. That’s the one I was thinking of. JEFF: Yup. CHUCK: Alright, Evan what are your picks? EVAN: Before I do that, I asked Eric in the back channel and he didn’t answer. Or now, he's starting to type. No, that wasn’t it. Eric, are you actually writing automated tests against your Vagrant deployments to test out your production deployment? ERIC: I am not writing tests to test that I test my deployment. CHUCK: [Laughs] EVAN: The test you are doing is essentially a manual one; you run your deployment using Vagrant rather than doing it in production and double check it by… ERIC: Yeah, when you get to Puppet or Chef or any dev op stuff, you kind of realize that testing is a bitch. EVAN: Oh sure. ERIC: And the way I test is I'll get in there and I'll hack on a server and think like, “Okay, this is configured.” And then what I'll do using  Vagrant is blow away that server completely, build a new one from scratch, run my config again and make sure it's good, that gets most of the errors… I mean… EVAN: You just said a big one there. “Testing would be a bitch.” But to me, that sounds like an opportunity for more tools. JEFF: There is a tool out there… there is some rspec for Vagrant stuff out there, and it think that's  some rspec for Puppet out there. I don’t know about the Chef world, but to make sure that your Puppet configs have been spec’d, and to make sure all your Vagrant configs has been spec’d. And there some automation that gets added to the mix too. And because the end… sort of far into the spectrum,  when you go towards continuous deployment, you can have Jenkins spit out… Basically, have Jenkins fire up a new configuration. I have Vagrant ready to fire up something and do all your automated testing on Vagrant after the fact. But I mean, scale from… not scale, but provisional box from [unintelligible] basically then deploy the code, then do your automated testing, which is a step removed from your servers for continuous deployment. EVAN: What I would tend to think is that you would want something like a… you would want an acceptance testing tool for your deployment process, that would involve creating all those Vagrant boxes, and then actually trying to use your app as an actual user browser… simulated browser, if you are talking about web app to make sure things are working correctly – among other things, maybe. ERIC: Realistically, the further you get into this rabbit hole, the worse it gets. Like Puppet, I know as a company, they are doing more of the testing stuff and it's hard. And to be realistic about it, I didn’t get into when you guys talked about TDD, because I could rant for hours about it, but if your Puppet configuration is wrong and your database server goes offline, you are going to know five seconds later about it. You don’t need to spend 40 hours trying to test for it. You can write a simple test or in my case, I have a Nagios that checks my server every minute. And so the cost of writing automate test to check something, versus the cost of actually just correcting really bad boo boo, it's so far weighted than just do the bare minimum and then just correct the boo boos as they come. So that’s how I look at it. If you are doing like 500 servers in your Amazon or whatever, then yeah you might spend time on testing that but for me, it's just impractical. CHUCK: I feel a dev ops episode coming on. EVAN: Yeah. I can't remember his last name, Will from Heroku, he’s on the PostgreSQL team, he says that they actually have a process, for example. So this is what I was thinking too as you were talking about it, that goes from machine to machine. Essentially talking to each PostgreSQL server, “Hey, are you live? Okay, cool.” JEFF: But you are talking about Heroku. How many PostgreSQL servers do they have? EVAN: A lot. JEFF: Exactly. EVAN: [Chuckles] JEFF: I mean, there's some threshold they cross when it became worth it, suddenly for them and probably not that suddenly. EVAN: Just imagine it would be that hard to iterate over a set of servers just connect and… JEFF: So why don’t you get on it? [Laughter] EVAN: On my free time. ERIC: Here’s the thing: if you wanna ping ten servers, yeah that’s fine. If you wanna go and login, get behind a firewall, get through your cluster and make sure Memcached is running, or Memcached didn’t reboot after your last puppet run, I mean you’d get into really complex problems. And because… JEFF: Not just the Memcached is running; that Memcached is running *and* it's configured the way that it needs to be configured. ERIC: Yeah, I mean it's tradeoffs could test it but… EVAN: But that’s also kind of the difference between… now we are getting into testing, that’s kind of the difference between an acceptance test and a unit test; you are not going to… JEFF: It's also the [unintelligible] that says 100% test coverage is where you need to be all the time. EVAN: 100% test coverage, you can still fail. Again, completely different topic. CHUCK: Yeah. ERIC: Evan, there's a post by DHH about a Bike Shed, I'll link it to you. [Laughter] EVAN: Yeah, you do that. CHUCK: Oh, and what do they do on this bike shed? EVAN: So other than being mean to me, Eric… I'm not saying, “Yeah, you should do this,” I'm saying, “This might be something worth thinking about.” That’s all. JEFF: Did you go watching the Twilight movie? CHUCK: [Laughs] EVAN: No, I didn’t watch the Twilight movie. I hate those things. CHUCK: Sparkling vampires? EVAN: No, I don’t have a Jar Jar stuffed animal either. ERIC: He’s got a Jar jar snuggie. CHUCK: [Laughs] EVAN: Don’t make me start linking more Jar Jar items. So my first pick is an article by Michael Feathers about how should on the outside be… or on the inside be functional. I was catching up on my Instapaper this morning, and kind of an interesting read. Mike is always pushing the bounds with the functional programming – at least in Ruby. And well, I’ve kind of find these stuff neat. Plus, not having side effects in your applications are considered a good thing, not having side effects can often be painful even though how well we write the databases, how we stores anything, but I mean, you have maintain an awful lot of state that leaves a margin for error. So that’s one pick. The other pick is we’re just talking about tools because this is Ruby episode, I'm particularly a fan of Pry lately. For those of you who might not  be familiar, Pry is a little bit like a debugger, but not really; it will let you pop into a console and IRB-like session in the middle of running your code –whether there’s test or not -- and it provides a whole bunch of really nice features that are not in the debugger. For example, one feature that saved me a lot of pain after already spending way too much time trying to figure out what's going on, is Pry’s ability to tell you where a piece of code is defined. So it helped me find this evil monkey patch that someone made to a gem I was using. And finally, my last pick would be Mass Effect 3, because that’s where I've been spending a lot of my time since I got back from conferencing and taking a small break between clients, is playing Mass Effect 3, which is a pretty darn cool game, with a pretty good story. CHUCK: Do you test drive your gaming? EVAN: I don’t test drive my gaming. I die a lot. CHUCK: [Chuckles] EVAN: So that’s manual testing. I die a lot. ERIC: So would that be a unit test or an acceptance test? EVAN: No, that’s manual testing, Eric. It's the worst kind. CHUCK: [Chuckles] Alright. I suppose I'm next. I'm not sure I picked this before, but I'm going to pick it again because I've been playing with it and I've been really liking it, and that is Scrivener. Basically, it's a very expensive, it's like $40 or something on the Apple AppStore, but it's a really nice way of outlining and building content. It's geared toward authors, but I've been using it to put together like some courses and digital products that I’ve been working on for content. Of course, I haven’t been doing that since last week because I've been under this time crunch for this client, but it's really nice. And you can break things down all the way up to the top level, and you kind of get an outline on the left, but you can get like notecards, and you can put summaries on the notecards and move them around; you can move cards on under each other, so that you can see the outline for one area, you click on the note card for that section, and you see the notecard for the subsections. Anyway, it's really, really nice. And it allows you to break stuff up the way that you kind of think about it. JEFF: It’s for book authors and before it hit the Mac AppStore, I think it was like $80 or $90. So $40 is not expensive. It's people like you that bitch about a $1 iPhone app, it took 100 hours to make or something. CHUCK: [Chuckles] JEFF: That’s a rant for another day. But Scrivener has some really cool stuff. It's got story boarding and actors, and you can do some amazing stuff with Scrivener. CHUCK: And it's got a really, really nice tutorial in it, so I actually spent like an hour or so working through the tutorial. And, “Oh okay, so this is how I do this and this is how I do that.” Just understanding all the organizational features in it just really makes a big difference. JEFF: It makes something else good too, don’t they make Mac Journal or something? They made something else I've used too that was pretty good. ERIC: Literature On Latte makes it. JEFF: Oh, they might have been bought then. CHUCK: Anyway, so I'm really liking it. And then as far as Ruby and Rails development goes, there are a couple of books or tutorials out there that I really recommend to people if you are just getting into Ruby on Rails. One of them is the Ruby on Rails tutorial by Michael Hartl. I think it's at That doesn’t sound right to me. I'll find it and link to it on the show notes. And then the other one is the book that I just read. In fact, it was out book club book for Ruby Rogues, and that is Crafting Rails Applications by José Valim. EVAN: Ooh, that’s pretty advanced book though. CHUCK: Yeah, I don’t know. I mean it really kind of pulls back the covers on how Rails work. EVAN: Yeah, and then I think that’s really cool. I was talking to James Edward Gray over twitter about it, and the first time I cracked that book about a year ago, my head hurt a bit. When I cracked it more recently,  “Oh, it makes sense now.” But then again, I'm a total moron, so what do I know. CHUCK: [Chuckles] EVAN: But I think it's a pretty advanced book. But if we are going to talk about learning Rails, you mentioned Michael Hartl’s tutorial. It's kind of unfair not to mention the Ruby Koans for Learning Ruby. JEFF: I think they are just called “Koans” EVAN: No, it's still on I don’t know how to pronounce it. CHUCK: It's spelled K-o-a-n. So make your own choice. JEFF: You should test drive that. EVAN: Okay. so for anyone who doesn't already know Ruby, the Ruby Koans are basically a bunch of failing automated tests that you are supposed to go in and on a test by test basis, fix them. And by doing that, because the way the tests are organized build up an understanding a Ruby pretty quickly overtime -- kind of experimentally. And I recommended them basically every single Ruby beginner who comes my way, and I've never heard any complaints. I've done the Koans, I guess one and a half times before now. And I've loved them too. There's so many niches that get covered in there. CHUCK: Yeah, absolutely. Those are the picks. So head on to, follow the path of enlightenment. Anyway, you can find us on iTunes, or if you are listening to something else, I had somebody recently say  on the Android, if that’s the way you listen to podcast, DoggCatcher is a really good way of getting podcasts. So anyway, you can just grab the RSS feed off of the website at, and you can get all of the episodes that way. And we’re up to episode 9. I'll probably have the episode re-recorded at Ruby conference up within the next week or so, just getting that worked out but I haven’t had time to rip the audio out of the video and take care of that. EVAN: Next week, the part of Evan Light will be played by someone else. Because I'll be on travel. CHUCK: Where are you going? EVAN: San Francisco. CHUCK: okay. other than that, we’ve got some stuff going on. I'm actually going to be out of town at the end of the month, because the Ruby Rogues are going to be on a session at Rails Conf. So anyway, if you  have suggestions for us, go to the website, click on “request a topic” and let us know what you wanna hear about. And we have been pulling these topics from that list, so it's definitely a good way to do that. And hopefully next week, we'll be able to talk about taxes and accounting, and stuff. And we will catch you all next week! Oh, one last thing… JEFF: We are not lawyers. CHUCK: [Chuckles] Last week, the episode came out, I had several people complain to me that it was like 58 minutes of dead air. If you have that copy of the episode, go back and redownload it. We put up a copy that  actually had sound on it, so you can hear us talk about Products. JEFF: That was Evan ranting about Jar Jar, and we just muted him. CHUCK: [Chuckles] EVAN: Instead of bleeping me for the whole episode? I couldn’t stop cursing. CHUCK: Alright.

Sign up for the Newsletter

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