The Ruby Gems Podcast
A Ruby Central podcast that takes an inside look at the people, projects, and progress shaping the Ruby community. Discover the gems in Ruby and connect to this vibrant group of amazing people.
The Ruby Gems Podcast
Adam McCrea: Judoscale
Adam McCrea shares how he turned a side project into JudoScale, a Ruby-focused auto-scaler now powering thousands of apps. We discuss his origins in the Ruby community, how he (mostly) bootstrapped the company, and admits he's pretty much living the dream. We also look ahead at new potential features like DinoSniper and proactive scaling.
Rocky Mountain Ruby is coming up, on October 6th, in Boulder, Colorado. It's a single-track, community-focused conference that always draws an amazing group of people. Tickets are on sale now, so if you're in the area, or if you're just looking for an excuse to spend some time in the Rockies, you should definitely check it out.
Welcome to the RubyGems podcast brought to you by Ruby Central, where we uncover the stories behind the code. We're your hosts. I'm Marty Haught.
David Hill:And I'm David Hill. auto-scaling platform for Ruby applications. Adam's been writing Ruby since 2007 and turned what started as an internal scaling tool into Rails AutoScale, then grew it into a full-time business reaching $300,000 in annual recurring revenue. As a solo bootstrapped founder, he's created an impressive suite of Ruby gems that integrate with popular job queue systems like Sidekick, delayedjob and GoodJob, helping thousands of Ruby developers automatically optimize their app performance across platforms like Heroku, render and Flyio. Join us as we explore Adam's Ruby journey, the technical challenges of building platform-agnostic gems, and how he transformed a simple internal tool into a thriving SaaS business. Welcome to the podcast, adam. Hey guys, thanks for having me.
Marty Haught:So I was noticing, Adam, that you were at Edgecase. Maybe was that your sort of start into the Ruby world.
Adam McCrea:Yeah, that was my first Rails job. That was back in 2007. Edgecase was like one of the sort of the original, like Rails consultancies. Back in the day there weren't a whole lot of consultancies just focused on Rails and, fortunately for me, there happened to be one in my town. I live in Columbus, ohio, and that's where Edgecase was. That was where it all started for me.
Marty Haught:Any interesting tales from that time? I mean, I remember Joe O'Brien was the primary one with Edgecase and also Jim Weirich worked there, and so I have great respect for Jim amazing work that he's done. So I just I'm curious if there's any stories you have to share.
Adam McCrea:Jim was just an amazing developer, a wonderful human. We miss him a ton. He actually worked in the Cincinnati office of Edgecase. I didn't get to work with him on any projects but I definitely got to hang out with him at a few conferences and things like that and just a pure joy to be around. Loved being around Jim, but the whole Edgecase team was awesome. I would say from that time what I remember is just learning continuously. I think if somebody who is just starting out has the opportunity to join an agency or consultancy, especially if it's in person, I would highly recommend that. I think that's the best way to get good, get experienced really quickly. So I'm really happy that I did that. I was at Edgecase for six years before I made the jump over to product but, yeah, definitely really thankful for my years doing that so, in that transition space, I guess what led you to doing what became judo scale?
David Hill:what were you doing, what were you working on at the time where that started to become enough of an issue that you felt like there was a problem to be solved?
Adam McCrea:Yeah, I was working for a small product company called Agent Pronto. Basically, we were doing like lead generation for real estate agents and we were running everything on Heroku and just really wasting a lot of money running at full scale during off hours and when we were low traffic and as a small team, we were trying to save money where we could. So it seemed clear that we needed to auto scale in some way. Heroka makes it easy to slide that dyno slider up and down. Obviously, we didn't want to do that manually every day. We wanted to automate that in some way. So we tried a couple of the autocalers that were available at the time this was 2016. And they just didn't work very well. They were really clunky, hard to use and did not work reliably. Expectations were not met.
Adam McCrea:I had that developer urge where it's like I can build a better version of this. So I had been for years seeking out side projects that may eventually someday become a product. I had the dream of running my own SaaS full-time and at the time it just kind of seemed like a dream, but I was eager to find something where I could maybe get started on that. So I thought you know, I'll try to build this autoscaler thing. The first version of it I built in a few weeks.
Adam McCrea:It had no front end, it was really specifically built for us Any configuration had to be done through a Rails console but proved out that the idea worked. And you know, before I started working on it, I asked my boss my boss, we were like a team of three, but I asked him if I build this thing in my spare time, would you be interested in using it and would I own the IP for it? And he said yeah, absolutely, marketplace, so that other people could install it. And from there I had this side business that I was running and it didn't explode. It was really slow growth, but I was able to just keep it going and year over year just kept growing more and more to the point where I was able to go full time on it in 2021.
David Hill:So the time that you were there at Agent Pronto? Was that what it was called? That was what it was called. Yeah, make sure I'm not making that up in my head. Was that also Rails work that you were there at Agent Pronto? Was that what it was called? That was what it was called. Yeah, make sure I'm not making that up in my head. Was that also Rails work that you were doing there?
Adam McCrea:Yeah, it was Rails work and when I had joined there everything was hosted on Engine Yard and so I had spearheaded the move to Heroku, which went great and we actually saved a lot of money on that move and it simplified a lot of things for us. But there was still that extra opportunity to substantially reduce our spend on our Heroku resources.
David Hill:So when you started building what became JudoScale, was there any kind of debate about maybe using a different technology stack than Ruby and Rails, or was it always going to be that? What made you continue to pick Rails for that?
Adam McCrea:I've been primarily a Rails dev since 2007. Since that moment I joined Edgecase. I had been falling in love with Rails since before I joined Edgecase and just kind of tinkering with it on my own, and once I had the opportunity to start doing it full time, I have not had the urge to use anything else. There are those who thrive on being a polyglot and learning all the different languages they can learn. I'm not one of those people. I have found something that I love. It works wonderfully and I'm going to keep using it until it doesn't serve my needs. So no, there was never any question. For me, rails was what I wanted to use and it has worked wonderfully.
Marty Haught:Great. I'm curious if you can share a little bit of your thought process behind how you modularized the application, your approach to the gems and what you may have learned doing that over the years.
Adam McCrea:Yeah. So talking about the gems, I should probably back up a little bit and talk about how JudoSkill works. We have a gem that our customers install into their application and that gem just reports metrics to our API. So it reports request metrics specifically request queue time, which we can get into, what that means, and job queue metrics, things like sidekick and rescue, good job, all that stuff and then on the app side we consume those metrics and use it for auto-scaling.
Adam McCrea:But for the gems, what's interesting is the very first version of the gem that I wrote. It was extremely simple because all I cared about was collecting requests, queue time from requests, and periodically sending that data to JudoScale, which was called Rails Autoscale at the time, but it's the same product. But over time we added support for autoscaling, worker dynos, and so now we're collecting job queue metrics. Initially that was just Sidekick, but then customers wanted delayed job, customers wanted rescue, customers wanted good job. I was just adding these things to the gem and one of the complexities that came about was it became really difficult to specify dependencies. We require this version of sidekick, but you might not be using sidekick at all If you're using delayed job. We require this version of delayed job.
Adam McCrea:So to be able to enforce those version dependencies, we kind of ripped the whole thing apart into separate gems. So now we have kind of a core gem that we call Judo Scale Ruby. Most people don't use that on its own, they'll use Judo Scale Rails, judo Scale Sidekick. So we have a separate gem for each, basically like framework or job backend, that we integrate with.
Adam McCrea:I was really conflicted on whether to go that route, because it's not quite as simple for our customers, because we can't just say, install this one gem, now we have to say install these two gems, and we have to ask them you know, which job backend do you use, before we tell them which gems to install. But it has been really nice having each gem be completely isolated and we're able to enforce those version dependencies. So it's clear which version of Sidekick we support and which version of rescue and delay job and so on. So yeah, that has worked really well and it means that when we need to support a new job backend, it just means building out a new gem, a new gem that's going to look a lot like our other gems, but yeah, it means that we don't have to update the main gem just to add a new job, backend.
David Hill:So as far as Judo scale the company goes, the company is fully bootstrapped right. There's no VC funding or anything like that involved. No, there's an asterisk there. Asterisk, okay, there is, there is. That's a fun story.
Adam McCrea:In 2021, we did take some funding from TinySeed. Tinyseed calls themselves like VC for bootstrappers or an accelerator program for bootstrappers, so it's a small bit of funding. It's $120,000, which was substantial to me at the time, but compared to VC it's a small amount of funding. But it's a remote accelerator program. So it got me into this community with other people who are doing the same thing. They have mentors who you can reach out to for help and certainly that little influx of cash was able to help me go full-time without feeling I was taking a huge risk. So I still own the vast majority of the company and make all of the decisions. I don't have to run decisions by them or anything, so they're an extremely hands-off owner. So I refer to JudoScal as being a mostly bootstrapped company, because we behave like a bootstrapped company, we act like a bootstrapped company, but technically not fully bootstrapped.
David Hill:A question about the bootstrap side of it, then, at least as someone who has never started a company, who still fantasizes about it periodically, because there is kind of like that idealized goal of not answering to another boss who is not like yourself, right? What has that experience been like, of transitioning from being an employee to running your own business and bootstrapping it, mostly to running your own business and bootstrapping it?
Adam McCrea:mostly, it's really easy to forget that I am living my dream. I have to continually remind myself that, because I really am living my dream and when I step back it's amazing and wonderful and it's all the things that I had wanted it to be. At the same time, every day, I'm the one who has to make all the decisions. There's nobody else who I can deflect to. There's nobody else who I can lean on to take any sort of accountability for anything like it all comes to me and that's a lot of pressure sometimes and it's a lot of stress sometimes.
Adam McCrea:We had our worst production outage ever a couple weeks ago and it was just a horrible feeling, knowing that like I had let our customers down in this way. And it would be great if I could somehow separate myself from the business and I try to do that to some extent. But at the end of the day, when JudoSkill lets its customers down, I feel like I've personally let them down and that can be tough. But the reality is it's great being my own boss. It's great getting to decide what I work on every day. It's great being able to make technical decisions without really needing permission from anybody. I do discuss, collaborate with Carlos on my team for all that stuff. But it's been wonderful and stressful and all the things.
Marty Haught:I saw that you, while building Geoudo Scale, were working at various product companies, including YNAB, which I'm curious about, but can you tell us maybe more about your motivations and your thoughts about as you're working at those companies and you were bootstrapping Judo Scale? How did that go and what were you thinking about?
Adam McCrea:Yeah, I will say, one of the things that really helped me to run JudoSkill as a side project for over four years was being in the Heroku marketplace. I really sort of leaned on that distribution channel and basically I ignored marketing for those years. I built this product and I just waited on people to find the product through the Heroku add-on system and if it weren't for that, I would not be here talking to you right now. It would not have grown. We would all love to be able to just build a good product and people would just find it, but that's usually not the case. If you can find a good marketplace to go into, that can work over a long enough timeline. But it was slow. I needed to be patient.
Adam McCrea:But the reality is that for those four years I was working nights and weekends on the product. I was never really in a mode of up until 2 am working on it and I was able to keep the pace very maintainable. It was a few hours and a couple evenings throughout the week. It was a few hours on the weekend. It was helpful that I kept the product very focused and very simple. It solved one problem At the time it had two screens. It was just a very simple product that did one thing and did it well. And I iterated on it over time, adding the worker, auto-scaling, adding different platforms eventually, and that kind of thing. But keeping the product simple, being in a marketplace and really just forcing myself to keep the pace manageable, I think, is what helped me keep going for all those years without burning out, did you?
Marty Haught:find that you were observing and picking up things from those product companies that you then would apply to JudoScale, or was it more like? No, that's just a job where I was doing engineering. I didn't really think of it as how are they approaching product, how are they succeeding or not succeeding, making good choices?
Adam McCrea:I probably brought some things over from Agent Pronto because we were such a small team, but when I went to YNAB, ynab was a substantially larger team. Our engineering team was maybe 25 when I was there. I think they've grown substantially since then and a team of one is going to operate so differently than a team of 20, way differently than a team of 100. So were there things that I learned on the way? I'm sure that I did, but I can't really point to anything because I just feel like operating solo for so long, it's just a whole different world. I was responsible for everything, whereas at my product companies I was responsible for coding. At JudoScale I'm responsible for design, I'm responsible for dev, I'm responsible for determining product direction, marketing support, all the things you know.
Marty Haught:So with TinySeed, I'm curious because I'm not familiar with their program. How did that help you? I mean, I imagine it helped a lot, but I'm curious if you can kind of go into details of how it helped you as a business owner and then like any sort of advice you'd give to others in a similar spot where they're bootstrapping and maybe considering something like that.
Adam McCrea:It helped me in a couple of ways. The money was helpful. The money is what? Sure, I'm a risk-averse person and my wife even more so than I am. So making the jump from full-time senior software developer salary to running my own business, being responsible for everything myself, needing to find health insurance on the independent market all these things was a super scary jump. And Rails Autoscale at the time was at a point where I could just about match my salary with the product. But having a little extra money in the bank gave confidence that like, okay, we can do this without a whole lot of risk. So the money made a difference.
Adam McCrea:I didn't really lean on the mentors in TinySeed the way most other folks I know in TinySeed do. For me, it was almost just more about feeling like I was part of a community who was doing similar things, People who I could bounce ideas off of and people who had my back, people who could empathize with the stuff that I was going through. Because being a solo founder can be really lonely. It can feel really isolating. I envy other folks with co-founders, but of course it's a mixed bag. The great thing about being a solo founder is I don't have to answer to anybody. The bad part is you don't have anybody else to talk to Exactly yeah.
Adam McCrea:So, yeah, I would say advice find a community. You're going to need people who are doing similar things to bounce ideas off of, even if you don't find something like TinySeed. Tinyseed is tightly related to the MicroConf community and the MicroConf conferences. So, yeah, definitely be a part of that MicroConf community and find some people doing similar things in there. Get a co-founder if it's a natural fit, but don't force it, because if it's not somebody that you really work well with, it can end really badly, and I think I already touched on this.
Adam McCrea:The thing that really helped was launching into a marketplace so that I didn't have to really focus on marketing from the get-go, and just the fact that I was able to run it as a side project for several years. If I went into it saying I'm going to go full-time within a year, well, that would have been incredibly stressful. The reality is, saas businesses take time to grow. We read stories about the ones that hit hockey stick growth and overnight success. Most of them, that's not the case. Most of them take a long time to grow, and so you've got to be patient. You got to be in it for the long haul.
David Hill:So, speaking of your marketing efforts, I have to ask about your ads for lack of a better word that you did for Drew during the RubyConf last year and then for your podcast that you've been sponsoring the process of coming up with those ads, listening to them, I'm always entertained, I'm always laughing. There's got to be a couple of good stories of just how and why and where you started deciding to do those.
Adam McCrea:I just really don't like to do the thing that's expected. So when I knew I needed to start taking marketing more seriously and doing some ads and that kind of thing, I'm like I don't want to make ads that sound like other ads, I want to stand out in some way. A friend of mine, john, who I worked with at a previous job and he lives in town with me. He and I get together once a week at a coworking space here and he kind of acts as almost like a co-founder, advisor, therapist, brainstorm partner. So we get together and we just like we don't really do work on code at all, it's all about just brainstorming and talking through ideas for the company, ideas for marketing. And he always pushes me out of my comfort zone. We'll have a crazy idea and I'm like, yeah, but I'm not going to do that. And he's like, oh, we're going to do that.
Adam McCrea:So when I think back to the commercial that we made for RubyConf last year, I had reached out to Drew about sponsoring his Ruby game show that he's done at several conferences and he told me if we wanted to, we could make a 30 second commercial and he would show it from stage. The only requirement is that it had to be funny. I was like, oh, that's way too much pressure, I'm not going to do that. And john was like, oh, yeah, we are.
Adam McCrea:So I don't even remember how the idea came about, but eventually we landed on doing a spoof of a billy mays style infomercial for the judo scale, which is an actual scale. We recorded it in his kitchen. I had a ridiculous amount of fun editing it and yeah, it was a big hit. People got a good laugh out of it and that felt really good that it went over well, because the kind of thing so far out of my comfort zone to just be like making a fool out of myself like that, I'm just like cringing when it's being shown from the stage. But people have said a lot of nice things about it, so I don't think we went wrong there.
David Hill:I remember laughing quite a bit. And then I was listening to Drew's podcast this morning and when your ad comes on, did you know that his bright red jacket is dyed in the blood of Nodejs developers? I was like who came up with that line?
Adam McCrea:That's amazing, I own that one.
David Hill:yeah, the first line of an ad's got to hook somebody somehow and like what's the most outrageous thing, I could say that was pretty significant yeah I've always enjoyed the ads, because normally ads in like the podcast space and everything are things that I tend to be like how many times can I hit the skip button to skip forward to where the content actually is? I never do that with your ads because they're entertaining. It was like I'm here for a good time. That makes me feel so good to hear.
Adam McCrea:They worked, for me at least Awesome, thank you.
David Hill:One of the call-outs that you do mention in the ads. I kind of wanted to see if we could dig into a little bit. You mentioned how JudoScale evaluates different metrics than what other autoscalers look like. So I was kind of curious if you could talk a little bit about what that process was like of figuring out what you needed to be looking at and realizing that this isn't what everybody else is doing for figuring out when you need to scale up or scale down.
Adam McCrea:Yeah, so from the initial days of Rails autoscale. From the very beginning, the other autoscalers that were available on Heroku autoscaled based on response time total response time which is problematic because every app has some slow endpoints and some fast endpoints. It's not consistent. Just because you have high response time does not mean you have a capacity issue. It just means your app might be slow. I had been reading a lot from Nate Berkopec at the time, who's been kind of the Rails performance guru for many, many years, and he was talking about this thing called request queue time, which is basically the time from a load balancer like Heroku's router is a load balancer receiving a request to the time when your application actually picks up and starts working on that request. That's called queue time because the requests queue up and they wait for your application, your Puma threads, your Puma workers or whatever to be able to pick up that request and start working on it. And if you don't have sufficient capacity, if all of your Puma threads and Puma workers are busy, requests are going to queue up and that queue time is going to increase. So Nate had been talking about request queue time and I don't remember at the time if he was talking about it with respect to autoscaling or just with respect to figuring out how much capacity you needed or knowing if you had a capacity issue. But that was the very first version of Rails Autoscale. That was my thought was I want to build an autoscaler based around request queue time. I didn't know if it would work. It was an experiment and it worked really really well and so that was like the whole focus for like the first year or two, until people started asking for background job autoscaling. The obvious metric to me for scaling background jobs was queue latency, because any given job, whether you explicitly state it or not, is going to have some sort of SLO, some service level objective. This job needs to be worked on within five seconds or maybe within five minutes, and we really encourage people to actually name their queues based on that slo. That's a whole separate conversation. Implicitly, there's an slo with any job, so you can actually auto scale based on that. You can say you know well, if this queue's latency is over five seconds, we need to scale up because we need to get caught up on that queue. So I built worker autoscaling around queue latency and it worked really well.
Adam McCrea:It wasn't until we actually started expanding beyond Heroku. Since we've expanded to render, to fly, to Amazon, ECS and Railway, I started realizing that these other platforms have native autoscalers and they almost always autoscale based on CPU. And I can see how that might feel natural because it feels like if you run out of capacity, your CPU is going to get too high and you'll need to autoscale. But the reality is, especially on the worker side, you can have a backed up job queue without your CPU being very high at all, because your workers could be doing a lot of IO. Cpu just ends up being a really poor proxy for capacity, especially on the background job side.
Adam McCrea:So, yeah, it's a hard thing from a marketing standpoint to be like, oh, we use a better metric. Because what does that mean? Yeah, what it really means is on the website using request queue time on the worker side using that queue latency, and no native autoscaler on a platform is going to be able to use those metrics. To get request queue time. You need something running as a rack middleware To get your sidekick queue latency. You need something in your app that's actually querying.
Adam McCrea:It's actually benchmarking those queue times, Exactly exactly, Whereas a platform whether it's Amazon, ECS or Render they can't get app-specific information like that. They can only get system-level metrics. And yeah, so that's what lets us use better metrics is because we are integrating into the frameworks themselves rather than just being a system-level autoscaler.
Marty Haught:I'm curious, Adam, what's been the hardest part of this journey of sort of launching Judah Scale and kind of scaling it up?
Adam McCrea:The hardest part is learning how to be my own boss and to be a kind boss to myself, because on any given day, the reality is I don't have to work. I need to keep up on our customer support and I want to keep improving the product, but the reality is usually there's nothing that urgently needs done. And yet, for some reason, I still stress out when I don't sit down at my desk before a reasonable time and if I don't have a super productive day, I feel bad about it. I'm still trying to figure out how to be okay with those things and leverage the benefits of being my own boss and getting to make the decisions and getting to work on what I want to when I want to.
Adam McCrea:It's hard. I think years of being an employee have just ingrained these expectations of myself that aren't inherently true. I don't have to work eight hours a day, but I feel like I haven't done enough if I haven't have to work eight hours a day, but I feel like I haven't done enough if I haven't worked eight hours a day. So I'm still trying to unlearn these habits. That's been the hardest thing by far.
David Hill:So what's next or on the horizon for Judo Scale? Do you have anything newer that you're working on, or is it just kind of status quo at this point?
Adam McCrea:A couple of things we're working on right now that we're excited about. We've had several customers. Their focus with auto-scaling is not saving money, it's quality of service. They want to make sure that their app is as performant as possible at all times. And request queue time is the best metric that we've found for measuring capacity, but it's still a reactive metric. Request queue time doesn't increase until capacity is strained. As a result, if your traffic spikes up really quickly, your customers might experience a slowdown before auto-scaling is able to kick in, because the spike happens. Then request queue time goes up. Then we trigger auto-scaling is able to kick in because the spike happens, then request queue time goes up. Then we trigger auto-scaling and new resources need to be provisioned.
Adam McCrea:So we've been working on a way of measuring utilization not CPU utilization but actually request utilization and we measure that by just how often are your web processes working on a request. So 50% utilization for us means half the time your web processes are not working on a request. That's been able to. Let us say well, if you want to operate with a whole bunch of extra headroom, you can run at 50% utilization or even 30% utilization. You're over-provisioned, but you know you're over-provisioned by a designated amount so that you're ready for those spikes. So it's a way of doing more proactive autoscaling versus reactive autoscaling. We've been testing that for a few months and it's going really well. We're going to be launching that soon.
Adam McCrea:And the other thing that we want to launch soon I'm not sure how soon we'll be able to launch it we're calling DinoSniper. It's a way to combat noisy neighbors on Heroku. So if you're on Heroku's standard Dinos, you've certainly noticed where you randomly get things slow down and it's not by anything you did your traffic didn't do it and it's because it's shared hardware. You've got neighbors that are consuming more than their share of the CPU or whatever, and the result means you might be running five dynos but one of those dynos is struggling. It's slow because it's got a noisy neighbor. So DinoSniper basically watches for those bad dynos and kills those bad dynos and starts a new one to combat that noisy neighbor issue.
David Hill:I like that. That's cool. Unfortunately, I know the dino is D-Y-N-O, but I'm imagining a T-Rex with a sniper rifle.
Adam McCrea:There's so many ideas for visualizations here for sure. Yeah, this is one of those things where we initially built it for Heroku with this idea of DinoSniper and I love the name. We've actually been running it ourselves for over two years and the only reason I haven't gone public with it is because I haven't built a UI that I'm satisfied with. Now that we've expanded to other platforms, it's like DinoSniper that's such a Heroku-specific name, but I love the name so much. So, yeah, that not necessarily going to be the name we launch with. We need to do some exploration to see how useful it is on other platforms, because we're not actually sure how much other platforms have the same sort of noisy neighbor issue. So we need to figure that out to decide whether it's going to be a Heroku specific feature, in which case we'll keep the name Dino Sniper, or whether it's going to be a more universal feature, in which case I don't know, but I love the name.
Marty Haught:It's a great name, that's so fun. Yeah, all right. So we are now at the point where we do our Ruby roundup. We've got five questions for you. No pressure, I'll go first. What's your go-to comfort food? No pressure, I'll go first. What's your go-to?
Adam McCrea:comfort food. I'm boring Pizza, I'll eat pizza every day of the week.
David Hill:My son would do that if we let him, so yeah, that's a perfectly acceptable answer.
Marty Haught:So I guess with pizza, because pizza is a fairly broad category.
Adam McCrea:Is there a particular kind of pizza? Unfortunately I cannot eat gluten. I have celiac disease, which means a lot of those are out of the picture. But I'm lucky that there's a lot of good gluten-free pizza these days and especially I love a good cauliflower crust. Back when I could eat gluten I loved Jet's pizza. I don't know if that's nationwide, it's a deep dish from I think they started in Michigan. Can't have that anymore, but still love some pizza Okay.
David Hill:Are you reading anything for fun right now?
Adam McCrea:This question always makes me feel really uncomfortable, because I do read a lot of fiction. I read it on my Kindle. I usually forget what I'm reading. I couldn't even tell you the name of the book that I'm reading right now. I check eBooks out of the library and as soon as I finish a book, I forget it completely. It's just a way to unwind and pass the time.
Marty Haught:So yeah, I'm reading something for fun, but I couldn't even tell you what. It is All right, any recent movies or TV shows that you're into.
Adam McCrea:I recently finished up the Studio on Apple TV with Seth Rogen and I loved it. The cinematography in this show just like blew me away, where they would do these single camera shots that like lasted for several minutes and followed these characters moving all around and the cameras swinging all over the place. You would think it might make you dizzy, but it's so engaging and I'm like I don't know how they did this. I don't know how they this. I don't know how they. It makes me wonder how many takes they did of these scenes. It was such a compelling show and shot like no other show I've ever seen.
Marty Haught:So the studio on Apple TV if you haven't seen it, highly recommended yeah, I remember there's a scene in Andor, season two that was a single camera capture. It was like, I think, two minutes long. And just hearing about how they did that and imagining how challenging it was for all the actors and the extras to like nail that in one take, wow, yeah, I couldn't imagine what has you excited in tech right now.
David Hill:I don't know if you guys have heard of AI.
Adam McCrea:It's like this big thing AI you say People are starting to talk about this.
David Hill:Just one or two people, barely noticeable.
Adam McCrea:I'm feeling some FOMO big time with AI. I'm using Cursor like a lot of other people, and I use AI assistance in my development. I don't know if I'm using cursor like a lot of other people and I use AI assistance in my development, and I don't know if I'm excited or terrified or depressed about the idea of using AI for entire future development, but I do hear from people who are actually having a lot of success with it, so I'm intrigued by it. At some point I'm sure I'll try it out. Everything's just moving so fast and there's so many different ways to do these things. I'm like, oh, am I excited by it? Yes, but I'm also overwhelmed by it. So it's like I'm dabbling in it, trying to explore AI, but at a moderate pace.
David Hill:I recently started using one of the AI coding assistants called Augment, and for actual code generation I have not been happy with it, but for more general guidance and things, I somehow corrupted my SQL instance on my development laptop yesterday, and so it was just kind of like help me figure out, diagnose what's going on and then tell me how to fix it. And it's like, yeah, it totally is. Like here's what you do. This is what it looks like. Your problem is Okay. Well, how do I fix that problem? Here's the commands to run in the terminal. Great, oh, look, that worked. Okay, what's next? And it's like yeah, I've got MySQL running again, Got a database backup imported into it, all thanks to just Augment, instead of just augment telling me what I needed to do, and so for certain things it's really great, but the code it generates is not great yet.
Adam McCrea:Yeah, it hallucinates, it makes things up all the time, but for those moments when it saves you hours of hair-pulling, debugging, it's amazing.
Marty Haught:All right, what's a favorite gem? Preferably one that's not well-known.
Adam McCrea:I don't know how well known it is, but I've really been enjoying Put Debuggerer. It's hard to say I hate the name of this gem, but I'll just say what it does is if you're a Put Debugger, if you're somebody who uses Puts to debug your code, Puts Debugger gives you a method called PD instead of Puts and all it does is it lists the line of code where it ran and it inspects the item in a very nice, pretty readable way. So it's just a better way of doing Puts-style debugging, which I do all the time still.
David Hill:I cannot believe I've never heard of this gem before. I am also a Putz debugger developer. This might just change my life now.
Adam McCrea:Just be advised. I think there is a gem called Putz Debugger, and the one I'm talking about is Putz Debuggerer.
Marty Haught:Okay, we'll make sure to capture that properly. In the show I found the right one.
Adam McCrea:Either that or I've got them backwards, I don't know. I hate the name of these gems.
Marty Haught:All right. Last question when can people find you on the internet?
Adam McCrea:I'm Adam logic on all the socials, but I'm honestly not very active on social media. So, like if you want to contact me, adam atjudoskillcom is the best way, or you can LinkedIn me. I'm Adam McRae on LinkedIn and if you send me a message, I will definitely receive it and happy to chat with anybody. Love to hear from folks who listen to this and if anything resonated with you, let me know.
Marty Haught:Awesome. Well, Adam, thank you so much for joining us today. This has been a lot of fun.
Adam McCrea:This has been super fun. Thank you guys for having me.
David Hill:Thank you so much for tuning into the Ruby Gems podcast. We hope you enjoyed this episode. You can find show notes and links to everything we discussed at rubygemspodcastcom.
Marty Haught:If you have a topic you'd like us to cover or have feedback, we'd love to hear from you. Please email podcast at rubycentralorg. If you enjoyed this episode, please subscribe and consider leaving a five-star review. It really helps others find the podcast. Until next time, thanks for being such a gem.
