00:45 - Introducing the Wood brothers and their work

• Upgrade Rails
• Hint.io
• Ben’s Twitter
• Joshua’s Twitter 3:05 - Upgrading Rails without breaking it6:25 - Working with clients with technical debt12:20 - Frequently seen projects and clients14:45 - Upgrading clients from older versions of Rails22:50 - Why do clients push off upgrading?28:10 - How do you know when it’s time to upgrade?34:35 - Finding the right clients
• Website
• Ruby Weekly 37:50 - Avoiding technical debt
• Rails Xss gem
• Bundler 40:30 - Upgrading Rails yourself
• https://guides.rubyonrails.org/
• contact@hint.io

Picks:

Suture Gem (Ben)Debride Gem (Ben)JRuby Truffle Project by Oracle (Josh)ThinkPads(Josh)Honeybadger IO (Josh)“A Rubyist’s Guide to Big-O Notation” blog post (Josh)Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time by Brian Tracey (Brian)Codefights (Brian)Basics of Mechanical Engineering by Paul D. Ronney (Jason)The Demon-haunted World by Carl Sagan (Jason)

Transcript

Jason:            Welcome to the Ruby Rogues podcast. I’m Jason Swett. Charles Maxwood is not here today. Here with us we have Brian Hogan.Brian:            Hello.James:           We have Josh Wood.Josh:             Hey there.James:           And Ben Wood.Ben:              Hey everybody.James:           By the way, probably no relation to Charles Maxwood right?Ben:              Maybe, but not that I’m aware of.Josh:             We’ve talked about it. I think we’ve decided that there’s no relation there.Jason:            I just hope people know we’re not having this whole Chuck’s family members on. You guys are from Upgrade Rails. What is that? Tell us about that.Josh:      Upgrade Rails is a service that we started. First of all, Ben and I were co-owners of  a Ruby Consultancy based in Vancouver, Washington which is right next door to Portland Oregon. And we happen to be brothers hence the last name.                     But Upgrade Rails is a service that we started specifically because we kept running to a lot of clients that have Rails Application that need to be operated but for whatever reason like their teams usually, they want them working on features. They don’t really want to stop and take time to do things like maintenance. It’s not usually the top of people’s list. We created Upgrade Rails as kind of a service for us to develop our own expertise. We feel that we can do it a lot faster and better than the typical teams that doesn’t do it all the time. We can help teams focus on their features and building their Rails application and their business rather than doing maintenance.Jason:           What kind of clients and apps have you worked with so far?Ben:              So far, we’ve upgraded CodePen. It was a lot of fun. they’re one of the better-known sites on the internet. I think they have a really high [00:02:09] rank. They are a code sharing site. If you hadn’t heard of them, really cool business and really cool people. It was a lot of fun to work with them.We’ve recently finished an upgrade for NationBuilder which is another pretty large Rails application. I’ve known them for a little while and there are also really awesome folks over there. We worked from anywhere from small projects that might take anywhere from a week to two weeks all the way up to multi-month projects that are stepping through from even Rails 2.0 all the way up to Rails 4.0, 2.0 or 5.0.Jason:            I’m really interested to hear this goes because I find your work a little bit terrifying because you’re  like stepping into this unknown code base. You’re going to upgrade their Rails version and it’s like there’s some risk to that. You could potentially upgrade it and since you’re not familiar with all the features, you could accidentally break something. How do you prevent against that kind of stuff?Josh:             Want to jump in there Ben?Ben:          Yeah. Absolutely. We have a process that we’ve been developing and that absolutely is the question. It is scary when you’re getting into a Rails upgrade. Especially in a code base that you’re not familiar with. I want to add something to what Joshua say about clients that we’re working with before I dive into answering that question. That is this that we’re currently working on a project that will likely take a year or more to actually upgrade the entire, I say application but actually there’s four applications. They are all Rails apps and they are all interconnected probably in ways that are not best practice like some coupling happening and stuff. We’re involved in this project to help our client basically get some footing and foundation and set them on the right path and then they’re going to be continuing on at some point beyond our involvement because it’ll be expensive to have us contract with them for a year or more. Especially when they do have a large internal team. They’re just needing some help. We’ve got projects that take a week or two. Josh did Code 10 upgrade and I believe a week and a half or two weeks. Is that right Josh? Like a week maybe?Josh:      Yeah. It was actually about a week exactly.Ben:          Yeah. That’s unusual. To make it clear, most people that come, if they have a week-long budget, that’s usually pretty ambitious. But it’s not unheard of if you got a relatively healthy code base. And say you’re going from Rails version 3.0 to Rails version 4.0 or Rails version 4.0 to Rails version 5.0 or something along those lines. It’s not completely out of the picture. You could be able to do something like that in a week.                 But we found that a lot of the projects that we get involved with, especially ones that are really far behind, it’s not just a Rails upgrade that they’re in need of. If you’ve made it 10 years without upgrading Rails, then there’s a really good chance that there’s some chronic like illness in your app. You’ve got some serious tech that’s going on, that’s eating away. It’s not just dependencies framework and other gems and stuff that need upgrading.                 That’s usually where we start. That’s why one of the preface with that is that it scary jumping into an application and most people’s approach to starting Rails upgrade is, “I guess we should get into the gem file and change the Rails version. Try to resolve all the dependencies then just start dealing with stuff as it comes and try to get the Rails constantly boot, something along those lines.” We’ve definitely taken that route before in our consultancy before we really became experts or before we bill expertise in this area. We took that most basic and naïve approach. I can definitely say it’s not the way to go because you absolutely do get lost in the upgrade. You end up in a place where so many things are broken at once, it’s like you’re treading water and you’re trying to swim out of it.Jason:            Do you have to limit the kinds of clients you work with? Because it seems like different people have different mindsets and not everybody understands that might have to make some initial investments is paying technical debt before you can justifiably work on an upgrade budget because otherwise it’s just going to be impossible. How do you deal with that?Ben:             That’s an excellent question. I would say we don’t limit the clients necessarily. I would say that we will limit our involvement if we’re in the scenario where client has a lot of technical debt that they need to pay down and we’re advising them, “Hey it’s not a good idea to start a Rails update project right now before you deal some of this stuff.” But for example, say you’ve got 30% of the code bases that doesn’t even used because there’s a bunch of code that hasn’t been touched in year and also hasn’t been removed. We would essential say, “Hey, here’s a list of things that we observed that need to be done and we can help you with this.” We would work with them to pay down some of that technical debt before we dive into an upgrade project.For example, in that project that I’m saying that probably that going to go on for a year or more. They’re current production version of Rails that they’re running is Rails 2.3 and they upgrade it from Rails 1.0 back in 2009, I think they did that upgrade. They’re on Ruby 187 and they have a mountain of technical debt that they need to deal with before they can realistically engage an upgrade. When we came to them, we have our kick off call and discovered that they actually started doing the Rails upgrade already, they dove into it. It’s hard to be disappointed when you hear from them that, “Hey, we got Rails [00:08:09].” At the same time it’s like, “But wait a second. It’s great that you’ve made some progress but you’re going to have to step back at some point and deal with this other stuff.” We’re in the project now so we’re finding out, “Okay, we’re lost in this. We’re lost in this thing that came up. It’s unexpected.” Some stuff that we’re familiar with because of doing past Rails upgrades but for them it’s stuff that’s coming as a surprise. That’s more difficult to deal with.Brian:           I’m interested in hearing a lot about those kinds of surprises that you find because I can imagine that’s the real value that you bring. Isn’t it? You bring that experience of having work done. Where is the development team whose upgrading that application they have the experience of [00:08:51] that application but you’ve seen stuff, man, you’ve seen things.Josh:      We seen some things, that’s true.Ben:          We got that crazy look in our eyes. Bloodshot eyes and all that.Brian:           The gem they were depending on that no longer exist that has been replaced for the brand. The one with a completely different API, those kinds of things.Ben:          Yup absolutely. One such example of that actually, in Rails 2.0 to Rails 3.0, if you’re looking at the change log you would think it’s a minor change. That is the default behavior of each string which has a concept of being HTML safe in Rails 3.0. In Rails 2.3, there’s no such thing. All strings were considered HTML safe. But if you’ve ever been working on Rails application, you’ve had a string that you ended up seeing escaped when it displayed in your browser, you’re actually seeing an HTML instead of seeing the results of these visually. You need to call HTML safe on the string or you need to say raw and then pass the string to it for to display properly. That’s something that was introduced in Rails 3.0, didn’t exisT in Rails 2.0. and so, there’s a lot of people have Rails 2.0 applications where they need to do work to ensure that their strings are not HTML escaped by the time it hits the browser. That’s something that if you ever done a Rails 2 upgrade, I can imagine you didn’t run into that at least a few times. In the application that we’re upgrading right now, that’s one of things that they kept. They’re just like, “We’re not sure why we have to say raw on this. It’s just escaping everything.”One of the things I want to mention about this is that in the change log, I should say in the Rails 3.0 release notes, there’s actually just a little bullet point under, this is actually over the action view section 7.4 and then down in 7.4.3 kind of worked all of other changes. There’s a bullet point that says you no longer need to each string to escape HTML output, it is on by default in all view templates. If you want the unescaped string call raw and then pass the string to it. As far as I know that’s like that’s where in the change log it says, “hey there’s this thing that you need to consider when you’re upgrading.” And yet it’s this huge thing. It’s like one of the main things when you’re upgrading for the Rails 2.0 to 3.0 that you end up having to account for. You end up touching a lot of files, touching a lot of code to resolve those issues.Josh:      I would say the biggest problem with that is that it fails everywhere and it fails silently. If you have really strong integration test or something like that, if you have a Cucumber or something like that it’s actually like testing the output. Maybe even running JavaScript enabled on those tests. You’re going to have a bunch of failing test but if you don’t have those tests then basically you’re going to constantly be running into pages that just don’t display properly. I don’t think there’s even a deprecation log for those just because that’s just strings. It’s a complicated issue.Jason:           Yup.Brian:           Would you think it’s safe to say that majority of the projects you undertake don’t have complex test suites like that?Josh:      Right. That’s actually a really good question. Just in terms of what do we see when people come to us, their test suites. I would say for people that are really far behind in their gem versions, Rails version for the most part have not had extensive test suites. It doesn’t mean that they don’t have any but for us to see 50% or 60% coverage is usually pretty good. If we see less than 50% coverage then, we’re going to have one of those conversations where it’s like, “We want to work with you and we can help you extend your test coverage but we don’t really advice embarking on this until you build up some coverage.” Not to say that 50% or 60% is ideal because it’s definitely not a much higher number.Relying on count number only tells you so much, right? Those tests, many of us knows somewhat of a lie. That’s a good metric I guess to help judge some basis where you’re test covers lies but especially if you’re dealing with legacy applications that have seen a lot of different hands is the code base, have not been very well maintained, maybe you have had people drop in that are new to Ruby development and maybe programming in general. You end up with stuff like really, really, really, long lines of code.You might have one line that you miss in covers that ends up being that majority of a complexity of a method. Not that I need to get into a [00:13:42] about that. My point is we try to take each case uniquely and judge what the risk is based on not only how many lines of code they have covered but also what to test if they’re well written. The critical parts of the apps are tested. If you got 50% test coverage and you’re testing all at least critical stuff that’s much different than having 50% test coverage and you’re testing all the most critical stuff. For example, if you have SaaS site or something like that would help that you’d have some test coverage inside of your subscription system and not maybe there’s some static pages or something that you decided not to test.                              We got a lot of clients that do not have a 100% test coverage or anything close to it and we work with them. To judge that risk sometimes it’s done in test coverage before we get started on the Rails upgrade.Jason:            Here’s another question that’s not super related to that but it popped into my mind a minute ago. We’re in Rails 5.0 today. It’s sounds like you might be dealing with some clients who are on Rails 2.0. How do you deal with that? Or even if its Rails 3.0? Anything that’s earlier than Rails 4.0 basically. It would take more than one version upgrade to get them up to 5.0. Do you do just one notch and say, “That’s good for now. Maybe at some point in the future, we’ll take another pass.” Or do you try to do it all at once? How do you approach that?Ben:          Usually what the scenario is, when someone is into us and they’re on an old version. There’s not very many people that are saying, “Hey, we’re on Rails 2.0 and we really just want to get to Rails 3.0.” In fact, we haven’t had that happen yet actually. If you’re on Rails 2.0 and you’re looking to upgrade it's typically because you’re saying, “Hey we’re way outside of any kind of community support on Rails and thus we’re out of security support.” If there’s security patches that are being made they’re not getting applied, not only to Rails 2.0 but they’re not getting applied to Rails 3.0. In fact, they’re not even getting applies to Rails 4.0 or 4.1. Currently only Rails 4.2 and Rails 5 are getting security patches and the rest of previous version of Rails are completely unsupported.                 People that are on an older version of Rails, like Rails 2.0, are usually coming to us and say, “Hey, what’s the lowest version of Rails that has security support.? Can you help us get there?” In this case of this project that we’re working on right now that’s going to be what they’re after is PCI compliance. They are looking to have some sort of security certifications. In order to do that they need to make sure they’ve shared up the foundations so to speak. And upgrading Rails and Ruby and also for example their production environment’s version of Linux and such is something that they’re doing.And to answer the other part of your question, it’s not just one step. We don’t jump from Rails version 2.0 to Rails version 4.2. We take them from Rails version 2.3 we would go to then 3.0 and then we’d go to 3.1 and then we go 3.2 and so on and so forth. 4.0, 4.1 to eventually go to 4.2. We don’t step through all skim patch version but we do step to reach to minor version. The reason for that is you get the deprecation warnings. You got to get the application to a stable place between steps. If you try to make a big leap between the versions we found that again you end up in that limbo space where everything is broken all the time and you’re kind of lost in it. You’re trying water.The ideal is basically by the office little pieces you can chew at a time and get things in those stable stays and hopefully you can get some stuff in the production. For example, I keep going back on this example because the it’s the project that we’re working on right now. We are planning to release a version on Rails 3.2 and they’re not going to stay at that version but we actually want to release a production environment and verify that yes, this is stable.If any issues pop up, we don’t appoint each one but we do choose ones that we want to deploy depending on what versions we’re doing into it. Typically, it’s going to be the last release of a major version. In the case of this upgrade that we’re doing if we’re going to go through the Rails 3.0 versions, we’re not going to release 3.0 or 3.1 but we are going to release the very last patch version of 3.2Josh:      I would add one thing. When you’re deciding what your upgrade path is going to be and like Ben said typically you’re stepping from minor release to major release and between major releases you don’t want to just jump straight from 2.0 to 4.0. I would say there is one case where I might consider doing that and I think you have to evaluate this on a case by case basis but if you say you’re on like Rails 2.3 and your app is relatively small, it can make sense. Time-wise and budget-wise that can actually cost you less if you decided to jump straight to Rails 5.0 for instance from Rails 2.3. The only caveat there is that’s more kin can to a like a rewrite or at least a port directly to app version.You’re going to be dealing with a lot more things where you’re like rewriting certain things maybe because you don’t have all the deprecation warnings. You just know that it’s the wrong code and it needs to be upgraded. That’s something to judge on a case by case basis but I have seen that work really well. Mainly for small code bases, small Rails apps. It is a big process to step between all the Rails versions and sometimes it’s actually last time to just to go straight but like I said, you just have to do a cost analysis for that and then choose whichever one is going to cost you less.Ben:              Yup. I can add something on the end of that as well. And that definitely is an option and instruction that sometimes it’s going to end up costing less. The considerations are things like if you’re on Rails 2.3 then there’s a chance that you’re not using tooling for your test suite that you’re going to want to use that is compatible by the time you get to Rails 5.0 and ruby 2.3. That means you can’t court the application and then say, “Okay, let’s run some test and see what passes.” You got to do work on your test suite and maybe swapping on you tool like migrating over something like many test hours back from test unit or whatever it is that you need some background. And that’s tricky because you’ve lost your ability to say, “Okay, we’ve made this step and we’ve upgraded things. Now we’re going to run our tests.” If you’re doing the process as you’re walking through the versions, you might make it to Rails 3.0 and then say, “Okay, before we move on to Rails 4.0, we’re going to actually take some time to migrate our tooling that we’re using on our test suite to something that is also compatible on Rails 3.0 but is also compatible in Rails 4.0 and beyond.” You can run the test one by one. As you’re converting them and see that, “Okay, this is still testing the same thing. We’re not changing behavior on the test of what’s testing.”That’s tricky when you make those big leaps. But as Josh, said in the right scenario it can still be the right choice and it is kind of a rewrite on those because for four reasons that like you have to consider things like, “Okay we actually have to almost rewrite our test.” And look at each one and see that what it was, what its intention was, what it was testing but it still testing that [00:22:43] on this latest version that we’ve jumped to.Brian:           I’m interested in some of the things that you said. Some of the things you eluded to. I’m going to ask direct question to pull it all together. You talking about people that are coming from version of Rails that are quite old now. What are the top reasons that people have put this off? And we can say lack of manpower and wanting to focus on things. But some other reasons that people may defer this. What are some of the reasons that you’ve heard from customers or clients?Ben:          Josh, do you want to answer that? You want to go?Josh:      Go for it.Ben:          Okay. I think that there’s probably number of reasons but the most common that we see is the, like I said, they’re not just deferring. This is being real honest. They’re not just deferring Rails upgrade, they’re deferring maintenance and health checks on their application. In my opinion, I think in most cases, the reason that they’re as far behind as they are is just a lack of oversight in the health of the code base in general. And that’s not the case in every scenario. There have been some upgrades that we’ve done that are not that. But usually those upgrades, they’re not the ones that are on Rails 2.0, they’re on Rails 3.0 or something. And they’ve said, “Wow, we had security support stuff until fairly recently and now we realize it’s time for us to bite the bullet and take this on.” Sometimes it’s funding that might kept them from diving into it, sometimes its features that are working infrastructural stuff that’s important.For example, I think I can say this. When we worked on NationBuilder, one of the reason that they brought us in is that their whole team was very focused on beefing up their infrastructure for elections. That’s NationBuilder is all about, building tools for political activism and political parties to have list and donations and all sorts of features like that.Around election time, once every four years they get basically the slant in their infrastructure if they’re not up to the challenge we’ll just crumble underneath the weight of it. Their whole team was focused on that kind and at the same time they’re saying, “It’s really important and valuable for us to get up to a more current version of Rails.” That way, I would say scenario that isn’t quite like that, it’s just been neglected. It was put off for a time and then they realized, “We need to have somebody help us get this done because we’re going to continue to put it off because we’ve got these other super high priorities that is consuming all of our time.”The other scenario is often just that there hasn’t been that oversight to say, “Hey, we're building up technical debt. We’re not paying a down.” At some point It’s going to come back to divide us to the point that they might hire somebody like us and we’re saying, “Hey, this is going to take you a year. Maybe, with a small team. We’re not talking about putting 20 people on but if you’ve got a couple of people working on it and you’re paying down all this technical debt, it might take you a year by the time you get through all the technical debt and then step to the Rails version stably and get them into a production environment.”Brian:           I was wondering if you’ve encountered people who have a fear of the process. Something like people put off going to the dentist, for example. They’re afraid of the pain, and they don’t really want to face it and they’re just putting it off as long as they possibly can. Not necessarily oversight but more of a direct, “You know I’m using some really old gems and I know that they’re no longer being maintained so I have to swap out all these things and thing like that.” That was another thing I was wondering about.Ben:          I think that’s a very common case. I think a lot of people know that they need to be doing this stuff. Upgrading is almost like exercising. Everyone knows they should be doing it but it’s hard, it takes a lot of discipline to do it regularly and it’s a lot easier not to do it. A lot of people end up in that situation. They know they need to do it and it’s just whether it’s the fear not learning to have to dedicate the time and the resources to it and it just gets pushed back.Ben:              Yup. And I’ll also add to that point that definitely at sometimes a fear what will happen if they do upgrade. If from past experiences they’ve learned that upgrading can be painful not just in the process of getting it done but also in the process of failing. Because we’ve definitely seen that before, customers come and say, “Hey, I really, really don’t want to upgrade because…” They fill in the blank and they get the story about how the last upgrade was a huge failure. They have lot of issues in production etc. But I know that it has to be done. Or they might be saying that, “Put it off this long because of how afraid I am but I finally come down to it, I need to do it.” That definitely is a scenario that happens as well. In addition, they’re just being afraid of embarking on the work because it’s so much and nobody likes to do it. It’s also sometimes, “I’m afraid of what this is going to actually do to my application. Is it going to damage our business?” Things of that nature.Brian:           Alright. What I was going to say is how do you know when it’s time to upgrade. How do you know? You don’t want to just jump on the latest version that comes out, right? How do you know? How do you strike that balance? How do you know when it’s time to upgrade?Ben:          That’s a good question. I would say, at the very least when you see some updates coming from the Rails community that the next minor version of Rails is coming out and that has implication for what version of Rails is going to be no longer supported for security patches, if you’re on that version or version before. That’s definitely a time to upgrade.I would advise to everybody, not necessarily to be on the bleeding edge of Rails necessarily, not that I’m against that but that’s not a requirement but to at least keep within security support of the Rails core team. That’s a rule of thumb. When it comes to deciding if you’re going to jump to the next version of Rails if that’s the current version, really, I’d say it’s just a matter of are there things that you want? Are there features that are going to benefit your business, that’s going to benefit your developers as they build things that can speed up your process? In most cases I would say probably. It doesn’t mean that you have to use action cable or something like that. There are plenty of other things that Rails that will increase productivity and smooth the process of future development, that sort of thing. I would recommend it, but it’s definitely not like, “Hey you’re not on the latest version of Rails, you got to get there immediately.” We’re not trying to preach that to people per se.Brian:           So you’re sort of saying right now to everybody that’s listening if you’re not on Rails 4.2 you had this probably time to have this conversations?Ben:          Absolutely yeah. If you want a version prior Rails 4.2 then you should think about this one you’re getting left behind. You are building that technical debt that eventually is going to be difficult to get out of because you got multiple version of Rails to go through. When Rails 5.1 comes out, if you want to get up to date you’re going to have to go through Rails 4.2, 5.0 and then go all the way to 5.1. That is going to be more difficult not just because it gets piled up but also there’s the security support factor which maybe not everybody’s concerned about the security and side of things but I would say you should be. Certainly not that.Jason:            I might also add that if you’re on a creaky old Rails 3.0 code base, you might have a harder time attracting and retaining talent, right? Nobody wants to work with the old code base.Ben:              Yeah. Absolutely. I would absolutely agree there that if you’re having a hard time retaining good talent and you’re using old tools and your code base has lot of tech debt that you’re not dealing with. You’re not going to retain people to work on it because they’re going to go find more interesting things to do, certainly.Josh:         One of their point that applies here, I don’t know about you guys but I like Stack Overflow a lot and I think a lot of developers out there use Stack Overflow and similar documentation tools to supplement their memorized knowledge.One of the things we run into is that the older the version of the Rails that you on, the more outdated the documentation is. It might take your developer twice the amount of time to find the answer that they need when they go and they Google something. They’re not going to just pick the first result for instance that is usually what you would do if you’re on the most widely used version of Rails. But they’re going to have to evaluate like what version is this, maybe it’s even a couple of version back they’re looking for. They have to find the right documentations or find the right question that was asked back in 2009 or whatever. That alone, if you consider your paying your developers by hour for their time usually, that alone can save you a lot of money if you’re the owner of an application for instance. That’s always a pretty interesting thought to me. That’s something we like to think about too. How can we save developer’s time which translates into saving money for the business that they work for?Ben:          That’s absolutely a valid point Josh. And I’ve got a quick story about that. just yesterday I was doing some research , I was building up a road map for this client. Which is a little different because normally we’re involved in upgrading all the way through the process, in this particular upgrade there’s at least a good chance that we’re going to be stopping up at some point they’re going to be continuing on. We’re building this really detailed road map. I’m trying to download everything that we currently have in our own processes, internal stuffs and wikis and whatnot. Try to put it in a document that they can have.Just yesterday I was reading an article but I think I got linked out on one of the Rails release that doc pages that was from the original author of Active Relation. I clicked the link and I’m reading it and I realized, “Hey, wait this is on the Wayback Machine. Why is that? Can I access this still?” And I found out no, I can’t. Literally this blog article that I found extremely enlightening because I wasn’t doing heavy Rails development at that time, I wasn’t reading this sorts of articles but now I’m very interested to find out what was their original intent behind Rail and how do they do this? That blogger who really doesn’t exist in the internet anymore. It’s on the Wayback Machine and you can find it there and that’s awesome. I love the Wayback Machine for that. But there definitely is an instruction saying the scenario where you don’t have the resources that you have when the version was new. If you’re on Rails 2.0 there’s a lot of blog articles and documentation stuff going around the internet at that time that might not just even exist anymore.Brian:            Yup. That was a pretty compelling reason to need to upgrade your Rails version. That’s helpful because even with I, obviously knowledge of Rails, it can be difficult to translate a Rails upgrade to a really immediate tangible ROI for all of that time, expense and risk. Those are some pretty compelling reasons to pull the trigger and do it.Ben:              Yup.Brian:            With these clients you work with. How do you find each other? Do you find them? Do they find you? How does that work?Ben:          You can find our website at upgraderails.com. The main source that we’ve had for clients lately is we’ve been advertising in Peter Cooper’s newsletter Ruby weekly and we’ve been running some ads in there throughout since around the spring of 2016. That’s how we met a lot of our clients. We’re a full-service consultancy at hint. We have clients. We got a lot of word of mouth clients. We have long terms clients that we’ve worked with that we also provide these types of services for. We have the typical sources that you would expect for like a consultancy or an agency. A lot of word of mouth but like I said, we’re doing some advertising for upgraderails.com and that’s where we found some of the clients we’ve been talking about.Jason:            Do those tend to be technical people who reach out to you?Ben:              The marketing side is what I’m working on the most. I’ve been targeting the CTO level of a team that has probably 10 plus developers on it sometimes a lot more. We work with some single founder types too. That doesn’t disqualify you if you don’t have a large team. There’s an appeal if you say you’re a CTO and you’re concerned about driving the technology forward and you want people working on some new features with the business, that sort of thing. You’re the person that knows that this stuff needs to be done. At the same time you’re not positioned where you don’t necessarily want to stop everyone and work on it. That’s usually how they end up finding us.Jason:            It’s probably pretty close to time to start getting to the picks. But anything we should touch on before we move on to that part of it?Josh:      I’ll start to throw a couple of things out there. One is that we’ve been talking a lot about what we do with Upgrade Rails and what we’ve been doing for customers and stuff. But I hope that the conversations so far have been a benefit to people that are maybe in the situation who need to upgrade and there’s some advice that they can learn. One of the things which we’re going to talk about which I won’t go into links with but it’s something that’s part of our process which is really valuable and I would love to see people doing it when they’re doing Rail Upgrades is to try to do things that you can in advance.We talk a little bit with doing the tech debt thing right? But there’s certain things that you can take on before you actually touch you gem file. For example, we’re talking earlier about that whole HTML safe thing between Rails 2.0 and 3.0. There’s a gem called Rails XSS that you can use in Rails 2.0 that’ll essentially give you the behavior of HTML string escaping in Rails 2.0. And the benefit of that is you can say, “Hey, this is going to be a major challenge in this upgrade and once we actually change our gem file and get Rails install and all that stuff, there’s going to be a lot of things broken. A lot of test are going to be failing for other reasons.” The benefit of taking care of this whole string escaping thing in that stable environment, your master branch on Rails 2.0 before you even touch your gem file again. It takes that when you can work on that problem on isolation if any of your test fail, you know why. You know it’s because of this string escaping thing.And you can even get into production at some point and say, “Hey, let’s see if we got any reports of issue, stuff that are test didn’t cover and our aid didn’t catch.” Ten you can move on the next thing.The next thing might be use Bundler. Bundler wasn’t used in Rails default until 3.0 but you can use Bundler in Rails 2.3. And there’s other things like that and with each step of upgrade, there’s stuff like that in Rails 3.0 before on 3.1. Stuff you can do 3.2 before going 4.0. That’s a tool in our toolbox that we’d like to share with the world. We definitely come up with it. I think we may initially got the idea from the post of how Github upgraded from Rails 2.3 to 3.0 and that’s one of the things that they did is that they ported stuff from the next version back into the current version. They actually took that to a whole another level to the point that they ported everything back so they can run Rails 2.0 or Rails 3.0 under the same code base which is pretty nuts but a very cool thing they did. That’s how they did it.Anyway that’s just a lesson we’ve learned that we definitely like to share. Look for opportunities to take things from the next version of Rails and pull them into your current version. Resolve all the issues before you actually make that jump in your gem in file. And then finally I’d say if you do end up in a situation where you need some help or expertise, we’re definitely available upgraderails.com. To consult, to ask as some questions and have us come on for a short period or have us come in for doing whole upgrade for that.Jason:            Awesome. I was just going to ask that. If somebody wants to do an upgrade themselves and maybe they don’t have the budget to hire somebody for help or anything like that. Are there any particular resources you’d recommend or can they just email you a question? What would you recommend?Ben:          I’ll answer that. Josh may have some things say about that as well. Honestly, I think it’s kind of silly but is definitely I must recommend which is that there’s these upgrade docs, right? And the tendency for people is to just jump into upgrade and to start seeing what issues that come up and go then go read the docs and see if the problem that they’re having relates to the issue or one of the issues that’s inside the upgrade docs. But I would say before you embark on upgrade thoroughly read the upgrade docs. Not every little thing is covered in there, certainly there’s other issues that you got to come into. For example, stuff that doesn’t have anything do for Rails, other dependencies and gems. But the tendency is for us the developers often myself, especially is to skim read things and I’m finally at a point where I feel like I’ve got a handle on all the changes and that is getting me the edge to connect the dots between things that might be interconnected. Our resources out there, they’re not too hard to find. The problem is actually getting yourself to read them thoroughly and not just skim over them before you get started. That’s my thought.Jason:            You’re saying it’s probably worth investing all the time to educate yourself and sharpen your ax before you chop down that tree.Ben:              Yeah. Exactly.Josh:             I’m hoping that we’re going to be able to do more, put more out there for the community in the form of blog post that sort of thing of how we do our process. But really like I said, that’s really the benefit that we can provide doing this all the time is that we, number one we have a lot more experience than the average team doing this since it’s primarily what we do. We’re building a process that is I think pretty unique to us and it incorporates all that experience, all the best practices that we’ve learned doing all these upgrades. That really gives us an edge to get things faster and even if it wasn’t faster, just to ensure their success and not running into like severe bugs and that sort of thing.                 I hope we can share more of that and definitely I’m happy to answer any emails that anyone would have about the upgrade process or just giving advice. You can always contact us at hint.io and happy to email.Jason:            Awesome. I’m going to transition this into picks. Ben, do you want to do your picks first?Ben:              Absolutely. I picked three things, all actually relating to I guess maybe more tech debt than upgrading. Josh and I were just at Ruby conf just last week and these are three gems that I learned about and I haven’t actually had a chance to use in depth yet. So don’t ask me too many questions because I probably can’t answer them but I’m really excited to start using them. I think they will be probably able to make them part of our process and I think people should check them out.                 The first one is the Suture Gem and that’s made by Justin Searls it’s github.com/testdouble/suture and it’s a refactoring tool for Ruby design to make it safe to change code that you don’t confidently understand which is a huge things not something that you see. We actually saw Justin and get a talk on this and kind of demo how it’s used and I got to say, it seems like magic.                 The next one is called Debride Gem. It’s from Seattle.rb actually I’m not sure if I’m correct about that authors, but anyways seattlerb/debride. It’s a static code analysis tool for finding potentially unused code or dead methods which is definitely one of the things when you’re embarking on upgrade. You can find code to delete, that’s code you don’t want to upgrade. I highly recommend doing.                 The other one is also a tool for finding unused code it’s called [00:44:53]. I think it’s a fairly neutral actually, that’s my understanding. Static and code analysis of dynamic languages is not 100% so you’re not going to find all of your methods that are unused. You’re also going to have some false positive and such so [00:45:12] is a tool that meant to stand in a gap there especially with the language like Ruby. And the idea is you would install it to your application, put it in your production environment, tell it to look at certain methods you’d install I think they call them probes. And what it does is it actually records to a database the number of times this that code path has been called. If it’s used at all in production and it’ll give you a date and then there’s a tool that will actually list out, “Hey, this method was called at least many times and here’s when.” That sort of thing. If you have a code and say maybe debride have pointed out to you or you’re just suspicious that maybe that wasn’t use, you could use [00:45:54] in production to actually see if that code is being used or not over the course of say a week or a month. If you’ve got a code that is untouched for a month, there’s a good chance that it will be touched, right? Those are my three. Pretty cool.Jason:            That sounds pretty useful. I’m going to go check those out. Josh do you want to do your picks?Josh:             Sure. My picks aren’t related to upgrading particularly. They’re just things I like. My first one is the JRuby Truffle Project by Oracle which I think is really cool. JRuby if you all know is an implementation of Ruby for the JBM. Some benefits include multi-threaded concurrency and it’s really fast compared to MRI. Some folks over Oracle had been working on an alternate interpreter and compiler for JRuby. It’s a lot simpler and apparently it’s 10 to 20 times faster than MRI. Or it will make JRuby 10 to 20 times faster. I thought that’s really cool. It’s doesn’t sound like it’s for production use yet, it’s experimental but I really think it’s a really neat project to follow, there’s recently a talk on it at Ruby Conf last week and I think we’re going to link a website for them, the show notes has a bunch of research papers and that sort of things. There’s a lot to dive into.                 My next pick is actually old ThinkPads running Linux this is kind of been a hobby of mine lately and I’ve been having a lot of fun with it. ThinkPad is a line of laptop by Lenovo. It’s previously by IBM and Lenovo bought them. The cool thing about ThinkPad is that you can buy them really cheap with pretty decent specs and a lot of people upgrade them. My favorite thing about them is that if you have no hardware expertise, you can upgrade them yourself. It’s a lot of fun way to learn Linux which I’ve been doing lately. They run Linux really well, and like I said for example I wanted to upgrade my screen to a better resolution in one of my think pads and I just bought the parts was able to follow the hardware manual that came with it and do it myself. That was a lot of fun kind of a weekend project.                And my last pick is actually, I don’t think if I mentioned this but I’m also the co-founder of Honeybadger IO which is an exception tracking application for Ruby specifically and one of my co-founders Star Horne who writes a lot of our blog post wrote a really interesting blog post. It’s called A Rubyist’s Guide to Big-O Notation. That’s a computer science concept. Big-O Notation is a Mathematical Notation that’s commonly used for describing the complexity of an algorithm and Star does a really good job of describing that in Ruby terms. If you haven’t heard of Big-O Notation, go check that out. I think we’ll have a link in the show notes and those are my picks.Jason:            Awesome. Brian?Brian:           I’ve got two that are relating to the things we’ve been talking about today. The first one that I got is a book called Eat That Frog!: 21 Great Ways to Stop Procrastinating and Get More Done in Less Time. It’s by Brian Tracy. It makes the assumption that if you have to wake up every morning you should do the most uncomfortable or most difficult thing first and if you’re talking about people who are maybe putting off the Rails Upgrade just remember that, that frog is going to keep staring at you over and over again until you eventually take care of it.                 And the other pick that I have is not related to previous pick which is about Big-O Notation. One of things that I personally believe is important is to keep your skills sharp. Keep your skills where they need to be. And one of things that I’ve been advocating for and doing, practicing every day is some exercises over codefights.com. CodeFights’ gives you some challenge problems and you can actually do them against other software developers in time and see who can solve the problem quicker. That’s some great box to practice against but it’s a lot more fun to do it with your co-workers and really challenge each other, keep up your skills.Jason:            Awesome. I’m going to continue my tradition of having picks that have nothing to do with anything. My first pick is this, I don’t know what the heck it is. I just found it somehow. It’s called Basics of Mechanical Engineering by this guy named Paul D. Ronney. I Goggled the guy out of curiosity. It showed him in a spacesuit. I don’t know who this guy is. This guide is just really great. It’s a really accessible guide to intro to mechanical engineering which is something I happen to have an interest in. I played Legos with my kids. I like to try to build contraptions with Lego technique and I figured it would be useful to go and learn some actual mechanical engineering fundamentals. That has been really cool.                     My other thing is a book by Carl Sagan called The Demon-Haunted World. It’s about how to know what’s true and what’s not true. It talks about some interesting stuff to do with the Reagan administration. I think the book was written in the 80’s. It talked about how the Reagan’s used to consult astrologers and stuff like that to make really important decisions. It’s kind of how a society can avoid that kind of hocus pocus. I thought that was a really interesting book. Again, nothing to do with anything. It’s interesting.                     Okay. I want to say thanks Josh and Ben for coming on the show. It’s been really informative and helpful. If you could just repeat where people can find you online and if you want to include Twitter handles or anything like that. Feel free. But just to make sure people have the right way to contact you. Can you share that again for us?Josh:             Sure. You can find our consultancy which is called Hint at hint.io. You can find Upgrade Rails at upgraderails.com. You can find Honeybadger at honeybadger.io. I’m @joshuap on twitter. Ben, you can drop your Twitter handle.Ben:              I’m @benjaminwood on Twitter.Jason:            Awesome. I think that’s a wrap. Thanks again.Ben:              Thanks guys. Bye.Josh:             Thank you. Thanks for having us.