The Changelog: Software Development, Open Source - API Wrappers and Ruby (Interview)

Episode Date: July 30, 2013

Adam Stacoviak and Andrew Thorp talk with Drew Blas of Chargify about API wrappers, Ruby, open source, and more.

Welcome back, everyone. This is The Change Log, where our members support a blog and podcast that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com and our past shows at 5by5.tv slash changelog. This show is hosted by myself, Adam Stachowiak, and also Andrew Thorpe. Andrew, say hello to my friend. Hey, how's it going, man? My lips are sticky. Yeah, I hear you.

Yeah. So speaking of sticky lips, tune in live every Tuesday at 5 p.m. Central Standard Time right here on 5x5. And this is Lucky Number episode 97. And we're joined by Drew Blass, a DevOps engineer at Chargify. He's a fellow Rubyist and is starting a DevOps class next month called Ultimate DevOps Academy. So, Drew, welcome to the show. Thanks a lot. Andrew, I'm going to let you steal this one away today because you invited Drew on the show. I know he's awesome, but I just don't have the uptake on him quite as much as you do. Yeah, that's fine.

I'll kind of give a little intro i uh was out in uh san francisco like two or three years ago and i actually went out to uh to dinner with lance wally drew and obviously you know who that is he's a guy over at chargeify um so i reached out to him not long ago and just said hey is there anyone at the chargeify i know chargeify specifically is the core is not open source but you know you guys are involved in open source. You're very active in open source. Some of the pieces of Chargify have been open sourced. So is there anyone there that you'd like to have on the show?

And then Drew came about. Here I am. So here you are, Drew. Why don't you give us a little bit of an intro to who you are, what you do at Chargify, what kind of stuff Chargify is doing in the open source world. Sure. So I joined Chargify about a year ago, and it's been a really great transition for me. I'm traditionally a developer, and with them, I've been recently doing a lot of operations

work, so kind of bridging some of that gap and focusing on our infrastructure and lets me play with all sorts of cool open source tools. And Chartify, if anybody doesn't know, does recurring subscription credit card billing. So if you're building your own SaaS app and want easy plug-in credit card subscriptions, that's what we do. And so we leverage a lot of big name open source doing that, not just Rails. Of course, we're heavy users of the ActiveMerchant gem, and we work hard to contribute back to as many of the things we use as possible.

The cool part about that is that Active Merchant started out to open source too, so you all use it and then contribute back as well. Yeah, it's a really good feedback cycle. So specifically with Chargify, I noticed that obviously the API wrappers are open source, and that's a pretty common thing because you release it via publicly available RubyGems. So that's pretty common for a company to open source something like that. But you guys, why don't you give us a little bit of the insight into what it looks like to work on specifically the API wrapper and who in-house works on that and how you all manage the open source project.

So we've got quite a few open source projects in addition to just the wrappers. You know, we have wrappers obviously for a large number of different languages because, you know, we want to be as compatible as possible. And so, you know, we've always got everybody kind of pitching in to help out and maintain those. And, of course, we can't have a developer in every language. So that's where the open source community at large really comes in helpful to work side by side with us and making sure they're up to date and they handle changes that we might make to the API and stuff like that. And so, you know, that's a really good part of it.

And then, of course, all the tools that we're using internally, we try and separate those out into pieces that we can then push back out into the community. You know, Shopify did that when they first opened up the active merchant gem. And, you know, so we try and follow a lot of that same sort of philosophy, take any of the pieces we can and then get them back out there. I heard talk just today about a new one for doing worldwide ISO region management for, like, lists of all the different principalities and things that, and integrating that into Rails. So we're always looking for ways we can extract that stuff out. Gotcha. So that's a, like I said, that's a kind of a standard procedure for how some of the companies that, you know,

work with open source kind of operate. But you guys do a few things that are different over at Chargify. Specifically, you've open sourced docs.chargeify.com. Yeah, that's a really cool one because anywhere that we might be lacking, we usually get pretty quick feedback for somebody to just go in and throw up a pull request and say, you know, hey, this wasn't explained really well

or here's a better way to explain this, or any time there's something like that. And then on top of that, we took our actual Cucumber features from the closed source part of our app and then put them into the docs as well. So the exact same Cucumber feature that says, exactly here's how you make an API request and here's what you should

expect as a response that we run our internal tests against. Those are right there in the docs and they're open source and available for viewing and editing. Yeah, that's a really neat idea. So do you know where the idea to open source the Cucumber features came from? I don't. It's something that happened really early on. And, you know, the guys we spawned off of Grasshopper, which is a telephone exchange 1-800 number service. And, you know, again, they were using a lot of

internal open source tools and just thought it was a really good way to kind of be as transparent as possible. Totally, yeah. I know that, you know, personally from my experience, one of the companies that I actually helped start with some friends of mine, my buddy Ryan Schlesinger, he was working with, not with Chargify, he was using Chargify. And he would kind of give back to a lot of the projects that he was using. And I think documentation was one of them. And he always had very, very good things to say about the response he got, you know, from his contributions to the open source pieces of Chargify. So I think that was, you know, a welcome change. I think that at times with some of the bigger open source projects, you can be kind of scared to, you know, get involved because

of the, you know, sometimes there's some of that elitist mentality and Chargify definitely, from my experience, has never had that. You guys have always been very open to submissions and ideas and contributions. So is that something that is kind of, you know, how does that culture get developed in-house, like to be very open to that, you know, company-wide? There's two big things I think that contribute to it. The first one is easy because, you know, there's only a couple of us. We have very, very little outside funding. You're pretty much just bootstrapped and expanding with our own profitability.

Everybody's really critical to that operation. Anytime somebody from the outside comes in and offers help, we're certainly more than happy to take it. You know, we're very, ironically, very humble in that regard. And the other one is, again, because of the small team, we just all really have a passion for, you know, doing everything we can to do the best we can for our customers in the community. And, you know, that's the attitude you have to have when you have so few people. And so it just comes naturally, you know, I don't feel the, the, I don't feel that I have to, you know, get approval before I turn around and open source something. If I've got a tool I've written on company time and I say, wow, this would be, this would be perfect to open source. I just do it. There's, you know, there's no red tape to that. Gotcha. Yeah. So speaking of tools that you've written on CompanyTime, I know there's, you got,

you know, you told me about a bunch of different ideas you had, but specifically one of them that you actually just open sourced today, I think, right? Did you want to kind of talk about that? Today's release is called, it's called Consignment, and it's a small web service that basically takes incoming messages and parses them and then redispatches them to other remote services. And so it's just an easy way. I kind of think of it like StatsD, but for data and information as opposed to just numeric metrics. And so you can take things like if you have a cron job, and when the cron job finishes and puts out a report, and instead of just shooting off an email or something, send it into consignment, and then consignment can look at it,

determine what action to take, and then do it. So it might parse the message, see if something went wrong. And then, you know, if something went wrong, it might send a pager duty alert, or if everything looks okay, it might just save it to a database for later reference, or it can send emails or do any number of different things with whatever logic you write. So it's just kind of a centralized way to really easily pop any kind of that information in and then turn around later and set up your rules for how you want to handle those messages. And you don't have to go back to wherever the message came from and keep changing things.

Gotcha. So this is a, looks like it's a Node project. Is that something that is used in-house in Charge of Eye or is that just like a weekend hack project that you... So this is my first open-source Node project, and I did Node just because I thought it was the simplest way to do non-blocking. There was going to be a lot of back-end calls to other remote services, calling out to PagerDuty or to an email service and all those things. And, you know, Node just seemed like the right fit to, then you don't have to put those into like a background queue or something. Gotcha. Yeah, it's a fun thing to

hack on for sure. Internally though, so you may have said this before i may have just kind of spaced out on it but uh does chargeify um do you see any any node happening internally with chargeify or is there any now or well we're definitely going to be putting uh consignment into pretty heavy use there's a lot of uh a lot of places that i can see it fitting in it's it in the same way like like I said with StatsD, you just throw StatsD reporters everywhere and then later on decide if they're useful or not, and you can do your analytics in Graphite or whatever. It's the same kind of thing. Oh, I'm building something and I might want to do something with this information later,

so I'll just throw it out to consignment. And then it might be six months down the road and I say, oh, I'd like to start getting an email about these. And you can just update consignment and say, hey, start sending me an email when this event happens. And so that's going to be really good, I think, on our operations front for things like cron jobs and backup reports and chef reports and all that kind of stuff. So this consignment, it's brand new, released here on the show today. So that's awesome. But it seems like you were looking for the solution and you didn't find it. Can you kind of tell the backstory on a few days ago? I just asked around uh i always get a lot of success

when i uh tweet out and ask my developer friends you know hey have you guys heard of service x or something that does this and uh you know i was looking for even a sas app that would do it and i just couldn't find anything that that was quite scratching that itch. You know, this is sort of a, it's sort of like a Zapier or an If This Then That, but much more developer-focused. And, you know, I had some specific requirements around writing my own code to be able to parse things later on. Just couldn't find anything. So I said, well, I'll just try and throw it together and see what happens.

Gotcha. So it sprung out of a need, sprung out of something that you, you know, a need. So you said you want to roll that back into Chargify. So was it specifically a Chargify need or a need that you had personally in a different project? I just felt like it's kind of something that comes up a lot anytime i'm i'm doing a new app whether it's with chargeify or whether it's you know a personal project or anything or where this same kind of thing just like you know stats d applies in so many different circumstances that i would just say oh it'd be nice if I could just do this with my cron jobs or something like that. And it came up so many times that I finally got fed up.

And when I couldn't find a solution, I said, well, it shouldn't be too hard to throw something together. So, I mean, the difficulty there was, I think the 20th, this is the 23rd. So on the 20th, you tweeted that out. So basically three days plus a half day. Yeah, well, if I don't get the answer on Twitter within like a day, it's probably buried and I'm not going to get the answer. So I figured I hadn't heard any responses, so might as well not waste any more daylight.

Gotcha. So another little project that you mentioned, but I think it's, I don't know if you are working on it and haven't open sourced it or if you haven't actually begun working on it, but you said you called it AutoCloud. Yeah. So this is the one I'm really excited about. I'm on a sabbatical right now for a couple of weeks with Chargify to take some personal time. My personal coding project will be to convert this for open sourcing. We use it very heavily internally. What it does is it's an idempotent control framework for Amazon Web Services. It replicates a lot of what their internal cloud formation tool does,

which is you write basically a description of what instances and what security groups and what network settings you want, and then it's responsible for making sure that you actually have those configured and set up and running inside AWS. But CloudFormation is JSON-based with a lot of sort of cludges to get things like fake variables and fake loops and if statements working. And it just made a lot more sense, at least to me personally, to just take Ruby and inspect the current state of the network via the API and then make the appropriate changes. And that way,

when you're writing your description and you say, hey, I want to have 10 instances of this, you can just use a regular Ruby loop instead of something weird. And if you want to have them all belong to a single security group, you can use a variable to do that instead of, again, some kind of weird foreign pseudo language. So that just fit a lot better with my personal workflow for managing things. And it's been a super powerful tool for us. It kind of turns it into just like we do at Chef where everything's idempotent. Gotcha. So this is something that you're using in production at Chargify now? Yep. It manages, you know, all of our launching of instances and making sure, you know, we have as many as we want. And if we're going to change a

security group, you know, you just change the configuration file that says, here's what security group X is supposed to look like. And it goes and it checks and it says, hey, the security group out on Amazon doesn't quite look like that. Let's change it and make it match up. And so it handles all that logic. Gotcha. Is this actually part of the core of Chargify that you're going to extract out or is this some other way that you're using this right now? So it's a separate app. It's basically its own command line tool, kind of like Chef.

And so just something that we run separately and it makes all the API calls to Amazon to do whatever it needs to do. So it's already its own tool, but it's got a lot of our custom logic and a lot of the library code is mixed in with our actual configuration files. So it's getting those separated so that it can be a more generic tool that, of course, takes a lot of time. Gotcha. So we'll come back to that, but this isn't your first hurrah with building something around Amazon, the Amazon AWS suite. So it looks like you've built probably the unofficial official Ruby wrapper for SES. Is that right? Yeah.

So SES, when it first came out, I was really excited to use it, and they didn't have a Ruby wrapper for it at the time, so I went and wrote one that was specific to it, and it's been kind of plugging along ever since. The API hasn't changed a lot and they haven't really added anything new to it. So, you know, it's certainly lived a very long, happy life. And eventually Amazon did release their own version into the major Ruby AWS SDK. But a lot of people still like to target specifically just SES and not bring in all those other dependencies. So it's a good choice. And SES, for those that don't know, is Amazon's, was it Simple Email Service, right? Yep. So it's just sending, you know, bulk transactional emails, basically.

Similar to like a SendGrid or... Yeah, SendGrid or Postmark or Mandrill or any of those. Gotcha. Was that the first open source project you worked on? No, but it's one of, I think, the most successful ones I've worked on. So it definitely was picked up really well by the community. It still gets support requests every once in a while and has uh you know has had a lot of pull requests some come in so it's it's definitely been been uh popular and and you know still requires work to maintain so

gotcha yeah one of our previous guests uh mike perham mike perham from uh sidekick he was telling us about how he got involved in open source like you know 20 years ago or something before you know before github and before like ruby and before before source forge before source forge he was you know he got involved before there was anywhere to put your code so it's like nowadays it's hard to imagine you know getting started without a tool like github or source forge or you know any of the bit buckets out there. I definitely respect that. So what was the first, what would you say your intro into open source and why you got started in that realm was? Oh, I've got a, this is a sad anecdote actually.

Really my intro into open source was trying to contribute to the Rails core way back in the days when they were still on track for their bug tracking and their pseudo pull requests. And I submitted patches to the core for issues that I was having or issues that somebody else had been reported and I offered to fix. And I probably did this six or seven times. I'd submit a patch, and then six months later,

somebody on the core team would finally look at it. And of course, by then, it didn't merge cleanly, especially when they were on Subversion. So they'd just come and they'd close it, and they'd say, no, it doesn't merge cleanly. Thanks anyway. Um, uh, you know, let us know when you fix it. Of course it worked when I submitted it, but, uh, uh, so that was kind of a, uh, uh, depressing start into, uh, uh, trying to, to help out. And, uh, luckily, luckily I wasn't deterred, though,

and managed to keep plugging away at it. What if they would have accepted it, though, and then when they merged it because they don't have the pleasures of Git, couldn't submit it with you, like the merge, like it does on GitHub, you know? Oh, I mean, I don't credit i don't i don't know that i care about that but i mean like getting the point like oh i contributed xyz you know that

that's what i mean like yeah that's that's nice too although if i if i recall like back in the uh uh early days of uh uh there was a script that would check if you had contributed something, like if you had contributed a patch, and it actually checked the track log to see if an issue that you had submitted a patch on had been accepted or something. So there was still a way to see, even if your name wasn't on the actual commit. Gotcha.

So the Ultimate DevOps Academy, where did the idea to do this come from? So it's just something I had kind of been thinking about for a long time. I've been doing a lot of different things to try and help mentor and teach. I've been trying to get my public speaking chops up. I was at Mountain West RubyConf and several others giving talks and doing Rails hotline and stuff like that.

And so, I don't know, I think this just came naturally from that, that it was an area where a class would be helpful and be a little more effective than doing a lot of one-on-one work. And so I decided to launch the Ultimate DevOps Academy and see if there was anybody interested. Have you got any interest in it early yet? Yeah, yeah. So far, the interest has been really good and uh the feedback's been really positive we still have seats available though it starts august 12th um ultimate devops.com which i thought that was a pretty awesome domain name to still be available so uh uh just goes to show you that devops hasn't uh you know become too mainstream yet or else you wouldn't be able to get a domain like that.

So yeah, there's still seats available and I'd love to have more people join up. And I'm excited to, I think it's going to be really paying for my time to do a lot of one-on-one work and help and support that, you know, just like if you need to call me and ask questions and stuff like that. But then it's also going to, I think, generate a lot of material, you know, lesson plans and everything like that, that I can, I can turn around and give back to the community as well. I was going to ask, cause we just had the last show, we had Jesse Wogelmott on the show and he runs Ruby Off Rails and part of his huge selling point to that course. So if you're looking to learn Ruby, that's a really good thing because during the process of his course he's he acts basically as a mentor to you you know so seems like you're trying to do

the same thing with uh with this to be able to kind of work one-on-one with someone yeah and and uh so i'm really excited about it i think it's i think it's going to go off really well and uh starts here in a few weeks. And by the end of it, I'll have a ton of live videos and lesson plans and everything. And so, of course, six months later, I'll be out of date and I'll have to start all over again. But that's the life we lead. Yeah. Are you going to be hitting on Vagrant at all in the course? I am, yeah. It'll definitely be a part of it.

I'm going to try and hit a little bit of everything, but also go pretty in-depth. We're going to take a pretty decent-sized Rails app and turn it into a complete production environment. We're not just going to be playing around with little bits and pieces, but we're going to have, you know, full redundancy, you know, full operationally sound infrastructure on which you could run, you know, serious traffic on. And, you know, I think sometimes there's a pretty big gap between the intro tutorials that a lot of people get into and then really being able to to you know batten down the hatches yeah it's a topic that we actually talk about often on the changelog and it's kenneth who you know was potentially going to join us but apparently fell off the earth uh wow we love kenneth um he he hit on it early you know earlier on you on a few months ago. He said it's like this tribal knowledge, right?

There's this gap between beginner and expert, and that's like the tribal knowledge region where you just have to kind of throw yourself into the fire and learn as you go. And it sounds like this is a great step in that direction of helping to share that tribal knowledge in a strategic, structured manner. What would you say the level of the, I guess, I don't know if you're calling them students or not, you're calling it an academy, so I've got to imagine they're called students, but registries, people that come and take the course with you, this intensive, what is the level that they need to be at with DevOps? So I would say you should be a programmer, and obviously it might be a little easier for Ruby programmers

because we're going to be focusing on Chef, although I kind of make the disclaimer that a lot of this, you know, the lesson plan is revolved around goals, so doing things like your goal is to write an automation script that gets you to a certain state. And you could do that with Puppet, or you could do it with Ansible or SaltStack or whatever. So it doesn't have to be Chef,

but obviously I'm going to teach what I know best. And so it should be developers who have programming experience and, you know, maybe don't have the operation chops that they'd like, you know, which I think comes up a lot. You get developers who can write lots of great code. And that's great when you have no customers. But then you turn around the next day and your app's really popular, and now your problem isn't writing your new features. The problem is keeping things running and scaling and expanding for the users that you have. I've got to take a little chuckle, though, publicly on your second line on knowledge prerequisites for the course.

It says highly recommended to be able to read understand and write simple Ruby programs but then you also put in parentheses work through tryruby.org at least twice I mean I guess I don't want to scare anybody away but I don't know so that's tough

I'm sure I'll have a wide variety of ability levels. And, you know, it's certainly, I make no bones that it's my first time doing a course in this fashion. I've taught a lot of in-person courses before, but never an online one. And so, you know, I'm going to have to take stock of the people in the class, and some of them might have it easy, and some of them might need more help, and I'll just have to help where I need to. So the class is going to be twice a week?

Well, it's one lesson a week or what is the well it's it's one lesson a week and what what i'll be doing is i'll i'll record i'll record the video um i'm actually working through like doing some test recordings this week um and and then put the video out and and kind of go in a pseudo-live fashion alongside with the students. So if we need to stop and talk about things or whatever, we can, but then they've also got the whole video to refer back to. So it's one lesson per week, but we're going to have multiple live chat and live audio sessions to talk about what's going on and answer questions. Gotcha. So the cost of this class is $999, so it's definitely an investment, but one that's worthwhile.

But after the initial course, you mentioned that you potentially would like to release open courseware, I think, as you put it? Yeah. So, um, so, you know, what, what I'll probably do is, is, um, try and package together, um, a good portion of it and, and, uh, you know, release it for, for free use and, uh, you know, to help as many people as I can. I mean, there's no use in me holding onto it and keeping it to myself. And like I said, you know, help as many people as I can. I mean, there's no use in me holding on to it and keeping it to myself. And like I said, you know, it'll be outdated in a year or so. Right. You know, let's make use of it while it's still good stuff to have. Any plans to do something like, for those that are familiar with like a Ruby Cones,

something like that to kind of step somebody through enlightenment of DevOps? Not so much Ruby itself, but DevOps? You know, I think it'd be a really good idea. I bet a lot of this might do the same thing in the goals from the lessons. And we'll just have to see how it goes. I definitely have my work cut out for me just for this, so I'm pretty focused on it. Well, if you're listening now or on the podcast

and you plan to go to this, give Drew some slack. It's his first time to go around, so share some grace. Yes. Well, cool. It sounds like it's going to be a fun time. It's ultimateDevOps.com to plug that for you. Definitely good luck with that. I hope it turns out to be incredible for you.

Yeah, thanks very much. I kind of wanted to roll back into the AutoCloud that we were talking about before. When you guys were sitting around in Chargify, we may have kind of touched on this, but was this something that you wrote that you spent, like, I don't know what your process or what your internal team, how your roles are split up or anything, but was AutoCloud something that you kind of rolled mostly yourself or was this a team project or internally now? It was just kind of something that came out of my personal needs. It wasn't like an initiative that was dictated from the top or anything like that. It was just, you know, we make very, very heavy use of automation for managing the individual servers. And it's a lot like test-driven development.

Once you get into that code as configuration sort of mindset for your systems, it kind of felt wrong to be going into the Amazon management console to make a security group change or or manually writing an individual api call to launch a new instance and it was like these are the types of things that just like with with uh when you're doing chef or puppet that you you want to have in a repository and that way you know you've got a log of the changes, hey, on this date, I added this rule on this date, I added five new servers to this auto scaling group, you know, all these kind of things. And then you've already got, you've always got a very

authoritative source for, for what's going on, not just on your individual servers, but on your infrastructure as a whole. And so, you know, it just seemed like a very good complement to that. And when we didn't have anything like that, you know, it kind of feels wrong. You can feel it in your gut. Yeah, so you said you're on like a sabbatical from Chargify right now. Is that to work on Ultimate DevOps, or are you going to work on AutoCloud, or what are you doing on your sabbatical from Chargify right now. Is that to work on Ultimate DevOps or are you going to work on AutoCloud? What are you doing on your sabbatical, as you put it?

Well, it's a really long vacation. you know, code on whatever I want to code with, with, you know, kind of no, uh, deliverable milestones hanging over my head and, and work on what interests me or play with things. Um, the big one for me lately is I've been working through the, uh, Matasano security challenges. Yeah. Um, and those are, are super fun. And after I did them the first time I went back through and I rewrote all of them in go. So, uh, again, just, you know, fun ways to do cool things in, in programming that I don't get to do every day. And so that's what I'm doing with my spare time. Cool.

Yeah. So, uh, with Mitchell, uh, Hashimoto, we've had him on the show from vagrant. Uh, we've had Solomon hikes or just a few weeks ago on the show from.cloud and Docker. Mitchell was – he built Vagrant out of a need internally he had for – I can't remember the company he was at, but they had a need for it. And he worked on it, and then it became really popular. So he left his company in his case in very good graces everything, but left to work on Vagrant full-time. Solomon Hikes, today, he was the CEO of DotCloud, and they started Docker. And he today announced that he hired a CEO to replace himself so that he could become the CTO and focus full-time on Docker.

Yeah, and he's very excited about it. So it's big news, and I think the whole community could be excited about that, to know that Docker is taking off, and it's going to get some big legs behind it to go even harder in development. So let's say AutoCloud kind of starts to take off in the same mold and becomes a real popular tool and and chargeify says you know we'd love for you to kind of lead this project up specifically and and maybe not even work on the chargeify core anymore would you welcome something like that is

that something that would interest you or uh it definitely would um but you know i i don't know it's it's not quite in the same league. Like, I mean, personally, Docker is one of the, is I'm such a huge fan boy of Docker and, um, you know, I'm waiting with bated breath for the day that they stick a production ready label on it. Um, so that I can start, I, you know, replacing huge swaths of our infrastructure to use it. But, you know, I think auto is quite a bit simpler of a tool than that. You know, it's not on the same level as something like Chef. It's smaller and, you know, it doesn't even necessarily need full-time, you know, work on it or improvements.

Because, you know, I mean, really all it's doing is just making one configuration match another configuration. And I hope to just have it kind of grow naturally. And as somebody, you know, we have it built to do security groups. And then tomorrow, if somebody says, Oh, I'd like for it to be able to manage, you know, some other AWS component, you know, then they can add that. And then the next day, if somebody says, Oh, I wish this would work for Rackspace cloud instead. Well, great. I hope, you you know we can make that happen too but uh um yeah that's the path that you seem to see a lot and i can i think that's kind of why i was asking is because they start off as you know these a lot these much smaller projects and they kind of grow into these when they kind of get grow in popularity then people say well this is awesome and i just want to mold it a little bit to use it you know in this way and it starts to kind of take off and grow uh grow legs and become a whole different monster so um that's the beauty of open source software

though that's you know with vagrant he was mitchell was telling us that you know different um images that you know he's had community support to write different, you know, support for different images. And it was, you know, I mean, that's the beauty of it. You don't, it's not all on you to do everything. And, you know, you can just kind of manage people that as they need different pieces, they can kind of get them in there. So that's the beauty of open source, man. That's why we do what we do.

Plus, it's nice to have people who like using the things that you wrote. Well, yeah, definitely. It's also, it's nice for people to tell you how awesome you are. Yeah. Say it again. All right. So everyone that listens to the changelog knows that we kind of asked two questions on every guest that we have on there. And the first one I'll ask you, Drew, to kind of get your input on is for a call to arms.

So whether it's something with Chargify or something that you know you've worked on specifically um you know with devops or uh consignment or anything like that do you kind of have a call to arms whether you would love to see the open source community get involved and help out with something um you know the the honest truth is i i just like to to have more people contributing overall. Like, you know, there's so many open source projects out there that need help, especially the smaller ones. And I think a lot of people use more of them than they realize. You know, just like if you go through your gem file and look at how many little gems that you might use on a regular basis and who have authors who, you know,

need help or need new features or have issues, it's so easy to find those. And thanks to the wonder of GitHub, you know, help find an open issue and do a pull request for it. And I think there's still lots of developers who get intimidated or, you know, just don't get involved and there's so many easy paths to it. And there's a lot of great, I wish I knew the name, but there's a lot of great services out there now that will help you find open issues on projects you care about to be able to jump in and help out. So I say the call to arms is do something.

Don't just sit on the sideline. That's something that we talk about a lot on the changelog. When I go to conferences or just my local Ruby groups, people ask me a question like, how do I get involved with open source? What do I do? I'm like, just find something you care about and just start doing it. It's like, find a project that you care about and go and look at their issues and start contributing code.

And you find that the majority of times when you get involved, when you, you know, try to start getting involved, the community is very supportive and very helpful. And if you're, you know, honest about, you know, this is my first time getting involved with open source, not that they hold your hand but they you know you just find it's a pretty welcoming community and most projects that are very active in open source they kind of have their guidelines and their standards and what you should or shouldn't do when contributing to open source so like you said we just tell people just just start just start doing that's that's kind of the key and the the truth of the matter, I think, almost universally, but especially on bigger projects,

I know the Rails core team has said this many times in the past, is what most open source projects need is not somebody who knows the internals to go and code a solution. What they need is a secretary. They need help from the community to look at open issues and try and reproduce them like somebody will open an issue and say here's my problem and it sits there because nobody knows like what the real cause is so what they really need is like hey look at it if there's not enough information respond to the original poster and you know ask for the information or try to

reproduce it yourself, follow the steps, and then see if you can dig a little bit deeper than the person before you did. And, you know, kind of unlock the key so that one of the core developers can just, you know, knows exactly what he needs to do to fix it sort of thing. So all that triage and just that user interaction and, and that's all, you, and that's all you have to have is a grasp of the English language. You don't have to know the internals of the project you want to help out. That's certainly an easy way to kind of, I mean, that's kind of how we handle bugs at Pure Charity, and we do the same thing.

We report bugs, and the very next step is to validate them. It's the same case here. It's like you're reporting an issue. It's a bug with the project or whatever, but that's pretty neat. So you weren't on the last show, Andrew, but I started to ask this new question. I thought it was kind of neat, but it doesn't always apply, so it's not always like your exact every show question. But I figured for Drew it might make sense.

So Drew, if you weren't programming in Ruby, what would you be programming in? The tough part is there aren't many languages that I don't enjoy. You know, every new language comes out, I go, boy, I wish I could just do that all the time. So, you know, I wish for the perfect language that did, I go, boy, I wish I could just do that all the time. So, you know, I wish for the perfect language that did whatever I want. Lately, I'm a really big fan of Go. And I've also been trying to, you know, just spread out into just about anything. That's exactly what Jesse said last week, too, when I asked the question. He was like, I want to learn Go.

That was two in a row. If you kind of like Ruby, but you, you know, like what I found, because if Ruby and Go both are kind of like interesting to you, Steve Klabnick, who, you know, most people know, we have him on the show every once in a while, he's a big proponent of Rust, the new-ish Mozilla language that is out. And I encourage people to check it out. It's really cool.

It's really cool. He's got a book on it too, doesn't he? Yeah, it's like an e-book that is in constant development because the language is so young and constant flux. But yeah, Rust, definitely worth checking out too. You know, I read a lot of the theory behind Rust, and it really resonated with me. And, of course, just like every other language I read, I go, yes, this sounds like a wonderful idea. That's funny. I thought I was the only person that that happened to, and I thought there was something wrong with me.

Because every time I read something about a new language, I'm like, this is it, the perfect language. But it's never the perfect language. Never. So Rust, I think, if it starts getting the same kind of traction that Go has been getting lately, I'll definitely take a bigger interest in it. Gotcha. So our last, I guess, standard question that, as you called them, Adam, which I think is a good way to describe them, is for a programming hero.

So someone you want to give a shout out to, Drew. Sure. You know, everybody that I meet at conferences and everything is so, you know, are always so genuine and so very nice. It's really, it shocks me all the time. But a couple stand out in my mind. James Edward Gray, who lives pretty close to me in Oklahoma. And he's a really awesome guy. And he definitely does a lot of contributing to open source.

And Evan Light is a good friend of mine. So a shout out to him. And, uh, he just joined, uh, Basho and he's going to be doing some Erlang hacking. So I'm pretty excited for him about that. And, uh, my boss at Chargify, Michael Klatt, he's a pretty cool guy too. So, uh, he, he definitely knows how to, uh, have a cool culture that you want to work for so uh quick plug chargeify is hiring if anybody uh ruby on rails devs so yeah i i uh i think was it was evan light he's the one with the he was very open about a lot of the personal stuff that he was going through yes yes that's correct so yeah i remember reading through his stuff and just was incredibly taken back by his candor. Yeah, he's a man with a bigger heart. He's tested every single day, and so my heart goes out to him for sure. Yeah, great guy, though, for sure. Absolutely. Cool.

I guess since we're done with these standard questions, we can go with these standard clothes of the show. Uh, no, Drew was, it was good having you in the show. I, I, uh, I knew, uh, Andrew lined up a good show when he had you on and we're big fans of Chargify. I think the story of Chargify for those listening that may not know it. I mean, y'all have a pretty wild story with how you kind of grew out of Grasshopper Labs and um I just think the story of the last five years of Grasshopper and or sorry um Chargify has been really really cool so yes it's you know for for we're kind of in part of the old guard ironically being only being only five years old. But, you know, that's a long time in this world.

And, you know, so we've got that. And we've kept it small. And, you know, it's really been a good ride for us. So we're really happy with that. You mentioned on the show, too, like I think closer to the middle, somewhere in there. But you mentioned how you guys grow organically based on your actual company's growth. And that's just something I've seen from you guys and have just always been taken back by that and always respected the way that you've approached the market and approached growth of the company too.

And the Michael that you mentioned as one of your heroes at Chargeify, is he one of the old guards? Because I remember somebody named Michael I met a while ago. Yeah, he was back with Grasshopper, and he basically is the first man to code on Chargeify back when it was still a Grasshopper internal product. Michael and I met up at a Future of Web Apps back in 2008, so I know for sure that was 2010. So, yeah, it's a nice attitude, and it lets us kind of guide our own ship.

And Lance, who's the CEO, he's a very genuine, very open guy. He plays with his hand on the table and it's very refreshing. Yeah. I'll let this just say, because you mentioned the jobs there. So if you're listening to the show, I mean, great place to work. So if you're a Rubyist or want to work on their stuff, head on over and say hello. But this has been episode 97 of the Change Log. We're almost to 100, Andrew.

Can you believe that? So close. We need to have a big party or something. So close. We'll have to have like an all-day Change Log or something like that, you know, for episode 100 or something. We'll have to do something. Nobody wants to listen to us talk that much. All day live.

Nothing but the Change Log. All open source, all live. But thanks, Drew, for coming on the show. Let's all say goodbye. something like all nobody wants to listen to us talk that much all day live nothing but the train blog all open source all live but thanks Drew for coming on the show let's let's all say goodbye all right thanks so much man

see ya We'll see you next time.