For years, the Rails community has been clamoring for Active Deployment, a magical out-of-the-box mechanism for deploying applications.  Today on the show, Cameron Dutro shares how you can deploy Rails apps on Kubernetes with Kuby.  De-stress your deployments today with these simple strategies.

Hey everybody and welcome back to another episode of the Ruby Rogues Podcast. This week on our panel we have Valentino Stoll. I'm Charles Maxwood

 

And now...

 

from Top End Devs. Quick reminder about Rails Remote Conf coming up at the end of September. We have a special guest this week, and that's Cameron Dutrote. Cameron, do you wanna just remind people who you are?

 

Sure, yeah, I'm Cameron Dutro. I work at GitHub and I am here to talk about a deployment solution that I wrote called Kubi.

 

Very cool. Now, Kube, you know, just doing a little bit of homework here. It does Docker Kubernetes magic. And yeah, you know, my DevOps skills used to be current and then they invented all this container stuff. So, yeah,

 

Right.

 

I'm kind of liking the idea of a Kube, right? Do you want to give people kind of the elevator pitch, you know, what it is, what it's for, for people to use stuff like that.

 

Yeah, for sure. And yeah, first of all, thanks for having me on. Kubi and deployment and something and stuff like that is really near and dear to my heart. And the actual story behind Kubi actually starts with an episode of the RubyRogues podcast.

 

Woo!

 

I know, it's kind of come in full circle. So let's see, I think it's, I'm going to have to look this up, but it's episode 300 something of the podcast. and talked about why, or sort of one of the problems or the holes that he sees in Rails, which is that there's no active deployment for Rails apps. And so what he meant by that was, we have all these other great frameworks in Rails for interacting with the database. We have active record for that and active storage for storing files in the cloud,

 

Uh huh.

 

action text, all these other cool frameworks, but we don't have anything for deployment. And that's kind of funny, like things that you want to do with your app. Once you're finished building it, you want to put it online somewhere and there's not really a set solution out of the box that Rails has for that. And so on the podcast, Stefan was saying like, I don't really know if that needs to be a tool or if it just needs to be an official Rails guide or what, but it would be nice to have some official guidance in that regard. So I heard that episode and thought that he was totally right and I didn't really understand you know, sort of a blessed path for that, for Rails. And so fast forward a couple years, didn't think that it was going to be me that was going to work on that because, like

 

Mm-hmm.

 

you mentioned, Chuck, my DevOps skills were not fantastic. And it wasn't something that I really had specialized in my career. So I was like, well, maybe one day, maybe Stefan himself will do this. Maybe somebody else will step up and build a deployment solution for Rails that is

 

Right.

 

kind of the de facto. But in the intervening years, nobody really did that. You know, kept that in the back of my mind. And then a couple of years later, the company I worked for at the time, Lumos Labs, started to use and adopt Kubernetes to deploy Lumasi.com, the big monolith that we had for Lumasi.com.

 

Mm-hmm.

 

And we used, initially we used Docker and ECS for that, the Elastic Container Service, which is like Amazon's

 

Right.

 

sort of precursor to Kubernetes. And ECS is fine, it's kind of bare bones. You know, everything runs in containers, but it's not particularly easy to use their interface. And, you know, it really just runs containers. It doesn't do anything else besides that. So no databases, you know, no Redis, for example, you'd have to set all that stuff up yourself manually. So we used that for a long time. And then hired somebody who actually had much more experience with Kubernetes. And he started to convert all of us over Kubernetes and also, you know, the we also adopted a deployment web app called Samson by Zendesk and started to sort of deploy everything with that setup. And, you know, there's a moment for me where I just I remember sort of watching over his shoulder and we were deploying the Masi.com for kind of the first time and I

 

Thanks for watching!

 

was watching the the output scroll by and watching the output from things stood up automatically. And it was just, it was one of those moments that you have sometimes in tech where you're just like super blown away by how just magical the tool is. I'll never forget how amazed I was that it was doing all these things automatically when you just would configure what you wanted the tool to do and then it would go do it and make sure your app was running and all the other important parts to make sure your app stays up. I mentioned that we had background jobs, I think, or most apps do. And so it would start up the background job processor and connect to a Redis. And all that stuff just kind of happened automatically. There was no intervention necessary. And so that was a real light bulb moment. And so when that happened, I thought, why don't we do this? Why doesn't Rails have something like this that runs on Kubernetes that anybody could take advantage of? And so that's how Kuby was born. You had asked what Kubi is, I just gave sorts of background. Kubi is

 

Mm-hmm.

 

a deployment tool. I want it to be active deployment for Rails. It's written to be very simple, minimal configuration. I think the tagline for a long time was, deploy your app with almost, use Kubernetes with almost no configuration because Kubernetes is kind of known for being very config heavy

 

Mm-hmm.

 

and Kubi is very config light. It makes a lot of intelligent default choices feel like you might expect as a Rails Dev. you can put your config in there and all your config really is is just a couple of credentials so you know I want to deploy to DigitalOcean or Linode or EKS, Azure's Kubernetes offering any of those we have plug-in providers for those things. You configure those, you tell it where you want to push your Docker image and then you run a few commands and next thing you know your app is online and being served and conserved traffic. So yeah that's that's kube in a nutshell.

 

Nice, yeah, I mean, this is the thing that's kind of hung me up is that, so I like running my app in a Docker container locally. I mean, it's really convenient because I don't have to go and like sandbox crap or use a gem set for our VM or anything like that, right? I just, hey, install the stuff I need. Okay, done, right? Oh, I need a different version of Ruby now, okay. It's really

 

Mm-hmm.

 

convenient locally. But then I started looking at Kubernetes, right? Because I've been hosting on DigitalOcean forever.

 

Yeah.

 

And I was thinking, okay, well, now I've got top end devs. I'm also incidentally using the same code base for a podcast playbook. And so it's got an admin system that I've put on a separate server from the main site that hosts all the courses and stuff for people. stuff going on with like Redis and PostgreSQL and things like that. And, uh, you know, I'm, I'm using kind of their cloud database hosting for that. But, you know, eventually I'm going to have to scale it, or at least I'm hoping eventually I'll have to scale it. Right. And so then I'm

 

Right.

 

going to need a load balancer and I'm going to need, you know, more than one server running this stuff. And so, um, I was thinking, oh, cool. I'll just, you know, I'll figure out Kubernetes and try and, and use it. was so overwhelming that I was just like, you know, maybe I'll just stick this on VPSs for right now.

 

Yeah.

 

And then hopefully when I have that problem, I'll also have budget to hire somebody who really can do this for me. And so

 

Yeah.

 

that's where this appeals to me, right? Is it's like, okay, well, now I can put this on Docker containers, I can use some kind of Docker or container registry, and then hopefully I can, I can do this on my own and be my own IT guy for a little longer before I have to hire somebody to manage all this stuff. And I'm assuming too at some scale, you're gonna want somebody that just does all the monitoring and management stuff. But for now, it's just me.

 

Yeah. Yeah, right. Well, no, I mean, that's really, I think, an important like point to make that, you know, web development and building websites, putting them online can be a very specialized job. Right. Like you talk about hiring an Ops person. That's really how a lot of companies are organized. There's the devs who work on the actual features. And then there are Ops people who make sure that the website's up and job title that's kind of common these days is site reliability engineer. So they're responsible for

 

Yeah.

 

making sure the site's up all the time. And, you know, there can sometimes be, you know, maybe a contentious relationship between the devs and the ops people. And that's, I think, really why DevOps became a thing, right? So now we've got people who do both dev and ops or do dev as part of ops. And so there's

 

Mm-hmm.

 

a lot more crossover there. But I want to also call out how learning curve of a lot of these ops tools, like not even just Kubernetes, but a lot of ops tools are really complicated.

 

Oh yeah.

 

They're geared much more toward, you know, someone who does it full time, someone who used to be a network or sysadmin, you know, who is like very familiar with firewall rules. And I mean, you know, networking in general, and that's really, in my experience, not the average Rails dev. Most average Rails devs are slinging code in Ruby and writing features and, you know, doing that stuff when it comes to the ops side, there's a lot less confidence they have there that what they're doing is the right thing and a lot of times, you know, they open up security holes. They don't mean to because they don't understand the tooling. And so, you know, when I started to realize is that most devs would rather not have to care about ops at all. They

 

Mm-hmm.

 

want to care about it exactly 0% of the time. And there are great tools out there. I mean, you have the opportunity as a dev to use, a bunch of different deployment solutions. It's not like the Rails world or even the web development world is really lacking tools in this regard. Like you can really get as deep or as shallow as you want. You could use Heroku, which is a phenomenal hosting platform.

 

Yeah.

 

Maybe not in the recent couple of years, but a recent couple of months, but certainly one of the most popular ones for Rails devs, it's so easy just get push and next thing you know, your apps online, all of the networking and database management for you. Phenomenal, absolutely phenomenal. And you can use elastic Beanstalk, you could use render. There's

 

Mm-hmm.

 

so many options. And, but I think that there's also a lot to be said for managing some of this on your own. Because I come from the world of Capistrano and copying PHP files up to an FTP server. And there's nothing simpler maybe than Git push, but there's also maybe the one step slightly less complicated even than that, is just copying some files up to a server, right? And that's essentially what Capistrano is doing. It just takes some files, it copies them up, maybe it clones your repository, and

 

Yeah.

 

then runs your app using system control or whatever. And there's a lot to be said for having sort of that level of simplicity or that level of control over your environment. You know, Capistrano, it's just a Ruby script and you have a bare metal server up somewhere or any VPS you can put stuff onto. as a developer, I kind of miss that. Like I don't want to have to depend on render or depend on ECS or any of these platforms. I want to be able to have this awesome experience and control that I get with Capistrano, but still have the power of something like Kubernetes or Docker Swarm or any of these orchestration tools. So, and in my opinion too, like most of these orchestration tools Docker Swarm like Kubernetes are much too complicated for the average person. And like I said, most devs don't want to think about those things. They want to think a layer up from the stack, but maybe not as high as Render or Heroku, right? So what I really want out of Kube is to be as flexible and as developer-friendly as Capstrono, but there's no vendor lock-in with it. It's just a tool that you run on your machine. It's not anything more than that. There's no hosted option. There's no vendor lock-in. and usable as just an average

 

Mm-hmm.

 

dev.

 

So I want to speak to some of this because, so I was using DigitalOcean's app platform for a while

 

Mm-hmm.

 

to host top end devs. And I started hearing from people that it would inexplicably go out, like

 

Mm.

 

my website would. And so I'd go look and I'd get this weird error from DigitalOcean. And I kept sending them support requests and they're good about answering them, would just randomly not

 

Hmm.

 

work. And it wasn't an error from my side, it was an error on their system. And so I moved everything over to Capistrano and a server on one of their droplets. If you're not familiar with droplets, that's DigitalOcean's VPS

 

Right.

 

option. So I set everything just like I expected to because I've used it for years. The problem I had was figuring out, okay, I've got this server that I need to run Puma, and I want to use Puma, Proxy behind Nginx, and blah, blah, blah. It works terrific

 

Hmm.

 

on my local machine, but I had to figure out how to make it a system and there wasn't good documentation out there for how to put that configuration file onto the server

 

Hmm.

 

so that Puma would actually just start up on its own. And then when I wanted to restart it, I could just tell the system control system to restart the Puma service. And

 

Mm-hmm.

 

I think I still have a bruise on my head from like three or four or five weeks ago when I did this, because I banged my head against the wall for like three days straight trying to get it up. And then, you know, once I had it up, It was like, well, flip, I'm copying this file over to any other server I have to set up for podcast playbook. And then the other issue I ran into was that I had to do the same thing for Sidekick. And it wasn't identical, right? It wasn't identical to setting up the Puma service. And so I had to go in there and fiddle with it until I set it up. And even now, I still don't know if it's running optimally. I just

 

Mm-hmm.

 

know that it works. And so, you know, being kind of a level simpler, or a level more complicated than a git push. And that's true after you have the server set up. And

 

Yeah.

 

all of the, okay, and I also needed to do all of the Rails stuff. And so I need all the dependencies there. And okay, I added a new dependency. And so now I have to go onto the server and install the C library that it relies on. And so I had to jump through all those hoops. Yeah, now when I need to deploy, just cap production deploy, right? And it just

 

Yeah.

 

goes. And even if I add a new gem, 99% of the gems I'm using are straight up Ruby. And so there's no dependency that I'm missing. But yeah, it was a giant hassle to set it up. And so that's the other thing is, is if there was some kind of, I mean, cause the containers just work. I just pulled down a Ruby container that's designed to run Rails and I'm basically done. And so that, that's the appeal that it has is, you know, yeah, I like the containers. I like the simplicity, but it's a headache. And I'd like to be

 

Yeah.

 

able to set up triggers so that, yeah, when I do a get push, it goes, oh, do you want to deploy this? And I say, yes, and then it just deploys it. Or I don't push to the production branch until I'm ready to deploy or something like that. Because the DigitalOcean app platform actually worked that way. I'd pushed

 

Mm.

 

the production branch automatically pull it down and deploy it.

 

Absolutely. Yeah, I think a lot of what you're describing is the pain that I also have gone through with with Capistrano. Like specifically the problem where so I gave a RailsConf talk about about Kubi and I mentioned and like something made it online to YouTube. A couple weeks ago, and one of the comments under the video was somebody saying yeah Capistrano is great, but it will fail. The first 19 times you try to run it.

 

Mm-hmm.

 

Because you haven't gotten everything you know figured out yet

 

Yeah.

 

and that's absolutely right like there's It's great. It's smooth sailing. It works really well. But you know, getting to that point and I feel like I had to do that every single time I made a new app, I had to go to play somewhere and like some weird thing was wrong. You know, like

 

Yep.

 

the version of CentOS or whatever that I was using, you know, didn't support installing the GCC compiler version that I needed. In fact, that's actually something that happened to us at Lumos. We had this old Cron server that used to, it was all provisioned with Chef, I think. And there were some scripts on there that were supposed to run every day that like our billing reconciliation and

 

I

 

would...

 

loved Chef until I didn't anymore.

 

Yeah, well, and Chef is great. It's just like, you know, Chef suffers from the same problems that

 

It

 

you

 

does.

 

would suffer from with Capistrano, right? Like it needs to go into a server and install things, but if the environment isn't exactly what it expects, it'll just blow up,

 

Yep.

 

right? So what happened to us, we had this old app, Cron server, that nobody wanted to move or migrate or touch because it handled all our billing reconciliation. And so one day, one of our, we had this bug, and that server, the billing stuff started to fail. And we were like, that's weird, what happened? It turns out that one of our engineers had upgraded the Rails app to Ruby 2.6, which introduced the new safe navigation operator. And so that code is the same code that was used on the AppCron servers. So everything worked fine in production because we upgraded the production servers to 2.6, but nobody thought to upgrade the AppCron server to 2.6. And so when the billing reconciliation code ran, there was a safe navigation in that code was literally a syntax error on Ruby 2.5, which is what this old server was running. And

 

Mm-hmm.

 

so we were like, oh, dang it. Okay, I guess we got to go in and upgrade this server. So we wanted to upgrade the server, but we couldn't install 2.6 because it depended, like the GCC that was on that system was too old. And so we were like, okay, let's upgrade GCC. There was no package available for that CentOS version. So we're like, okay, well, let's install it manually. And that also failed for some reason. So we're stuck with this yak shave where we, you know, like

 

Yeah.

 

we couldn't upgrade CentOS would mean that we'd have to go and reposition the AMI or the Amazon, you know, instance for this, which is the whole point of we didn't want to do that in the first place because it was

 

This

 

going

 

is

 

to be

 

why

 

super

 

I

 

painful

 

don't

 

to

 

use

 

migrate

 

passenger

 

everything

 

anymore.

 

over, right?

 

Because the same thing, you have to go deploy engine X by hand to make passenger happy.

 

Yep. Right, you just get stuck in this totally hellish cycle of like

 

Yeah.

 

not being able to do anything because you want to upgrade all of these things that depend on each

 

Yep.

 

other, right? So that's a lot of the pain that Docker solved, right? It was like, you

 

Oh,

 

know,

 

100%.

 

you don't need to worry about what the operating system has installed. You just put everything you need into this image and then that can be, you know, run anywhere.

 

Well, the other thing is, is that the build artifact that you create with Docker, like I, you know, I have Docker installed on my Mac,

 

Thanks for watching!

 

but if anybody else has Docker, right, with anywhere close to the same capabilities, and I tend to keep mine updated, so it'll run on the latest version of Docker, Docker

 

Mm-hmm.

 

desktop. They have a working artifact, right? I don't

 

Yep.

 

have to go tell them, go install all this crap on your computer, you

 

Exactly,

 

know.

 

exactly. Right, like whenever I get a new Mac and I'm trying to install like NocoGiri, I always have to go through the hell of trying to

 

Mm-hmm.

 

figure out LibX, SLT, and this other,

 

Yeah.

 

and fortunately it's just a lot of brew installs.

 

What are those flags? Yeah.

 

Right, what are the flag? Exactly, like what are the flags? Like SQLite

 

Yeah.

 

sometimes has problems, but if you just use that pre-built, like Rails,

 

Mm-hmm.

 

or I think it's a Ruby Docker image,

 

Yeah.

 

it has all of that stuff installed. So literally like gem install NocoGiri just works. Like you don't

 

Yep.

 

have to ever like mess around stuff anymore. So

 

Yep.

 

yeah, that's definitely the

 

The

 

power

 

other

 

of Docker.

 

one that gets me is the Postgres app.

 

This

 

And

 

is.

 

then it's, Oh, what's the magic path to,

 

Yeah.

 

you know, to get the PG

 

Yeah.

 

gem to play nicely with it anyway.

 

Yeah, exactly. Right. So, yeah, I'm going to go ahead and do that. I'm going to

 

And

 

go

 

then

 

ahead and

 

I

 

do

 

don't

 

that.

 

have

 

I'm going

 

the right

 

to go

 

version of Postgres installed in it. So now I've got it.

 

Yeah, it's such a massive pain. And that's like a lot of the, I don't know, a lot of the friction that I used to encounter

 

Yeah.

 

with Rails development. Even trying to get a new junior person set up with a Rails app. I mean, I worked at Twitter back when Twitter was still using Ruby. And every time somebody would come onto the team, we'd have to spend like three hours getting their laptop

 

Mm-hmm.

 

set up because there was so many obnoxious

 

Yep.

 

compile errors and whatnot, you know? So yeah, I'm glad that a lot of the problems that used to happen, that have been solved by Docker.

 

Yeah, one question that I have. I'm sorry, Valentino, I feel like I'm just hogging the mic.

 

I'll get to it. I have lists going here.

 

Okay. So one thing that I'm curious about though is like I'm using Docker Compose on my machine

 

and I'll see you next time. Bye.

 

and I know that there are sort of client side versions of Kubernetes that you can run on your

 

Mm.

 

Mac or whatever. So would this work there too so I can test out the whole ball of wax or?

 

Yeah, for sure. So let me step back real fast and just make sure that I've said this so that it's sort of loaded into our brains here. Kubernetes works with Docker images, not necessarily Docker images, but images built with Docker or a Docker adjacent tool. There's lots of

 

Okay.

 

other tools that also build images. And so that's what Kubernetes does. It takes an image and then we'll run it for you and make sure the networking is connected. Like, you know, if you want to connect to a MySQL, running in the same cluster, because the network is all set up for you. So that's what those two tools are doing. And that's what also a Kube does. It'll build an image out of your Rails app and install all the right packages and whatnot. And then we'll push that to a registry. So Docker registry, you push all of your images and then it'll run, you know, when you start your app and deploy it, the Kubernetes cluster will pull down those images and run them. So, okay, so I think we're on the same page there. Oh, and I've totally forgotten your question now. I'm sorry, what was your question?

 

So can I run this locally?

 

Oh, right, yes, okay, so all of that stuff can run locally because the registry and Kubernetes, all of that is runnable anywhere really, so a server or your laptop. Kube has a series of plugins called providers that will let you deploy to DigitalOcean or Linode. And there's also one that deploys to, uses this tool called Kind. And Kind is like a cluster that can run So you would just use the kind provider and then deploy to, you know, to kind essentially, and then that would just run on your machine. You could look, you know, hit the website, localhost 3000, like you would normally do. Thanks for watching!

 

I mean it all sounds great to me.

 

I'm glad to hear that.

 

I mean,

 

Yeah.

 

I got to jump in here. I mean, I'm torn. And from a certain point in a Ruby app or Rails app, I could totally see the allure of Kubernetes and Docker

 

Yeah.

 

and all that. My problem is more of like the low to middle tier apps, right? Like that need to change and

 

Easy.

 

don't need structure

 

Hmm,

 

overhead

 

yeah.

 

for the most part. I know that probably isn't the most use case because of the bohemists that are out there now. But I feel like there's still a huge number of people where maybe Kubernetes, maybe Overkill, and maybe Kube solves that, mitigating some of that overhead. I was playing with Kube, the Daku, which

 

Mm.

 

you can run the same Roku. And it's still hard to beat that

 

Mm-hmm.

 

be able to just

 

Yeah.

 

get push dacu the same way you would. But having run a dacu server before this morning and it worked really well, I was able to deploy

 

Totally.

 

to Linode,

 

Yeah.

 

it was great.

 

Yeah.

 

Yeah, totally.

 

But it's still, like you mentioned, Heroku, get push Heroku, there's an open source version of that, like

 

Mm-hmm.

 

upgrading is

 

Sure.

 

terribly painful. So I definitely see the alert of having something more manageable in Kubernetes make that transition easier, right? Like how does the upgrade process work for Kubernetes?

 

So you have actually hit on like the most difficult part of Kubernetes. I wish that... So yes, so Kubernetes, unfortunately, is very difficult to upgrade, mostly because the APIs and whatnot will change. And when I say APIs, I mean, you'll apply these resources to the cluster. It's all YAML config, right? that from you. You don't have to actually mess with that YAML config. But what it's doing behind the scenes is building up this large amount of YAML and then shoving it into the cluster and saying, you know, do what I want you to do with this YAML. You know, set up my networking and whatnot. What usually happens with a cluster, though, is that it gets into a particular state and that state can be... state that you created, you know, that could be created, or a state that an operator creates, an operator being... a special program running inside your cluster that will respond to requests to, for example, create a database, in our case, a Cockroach database or Postgres. And so there's some implicit state there too. And when it comes to upgrading the cluster, sometimes those upgrades work flawlessly because they try not to break anything between from the previous minor version to the next one. However, in my experience, rough upgrades. So 119 to 120 was pretty rough because they they move the ingress controller or the ingress API to a different namespace. And so Linode, for example, will automatically upgrade. Like if they'll give you an email they'll say hey we are no longer we're gonna deprecate support for this previous version that you're currently using. You need to go in and upgrade and if you don't we'll like force upgrade your cluster at this particular date, which is I think they have to do that because if they don't, they'll end up supporting these super old versions of all this stuff. But those upgrades, I mean, this just happened to my dad's construction company website. They forced her upgraded his to the latest version and it just, the whole thing went down. You know, like it was just not, I got this email from the uptime robot and it was like, your site's down because they forced upgraded you. So that story in Kubernetes is not very good right now. And correspondingly, that story is totally non-existent in Kube. And that's one of the things that I really would like to have a better answer for, and we don't currently have a good answer for it. What most people do in the Kubernetes world, even without Kube, is they'll create a new cluster, migrate

 

Thanks for watching!

 

everything to it sort of manually, and then deploy to that from then on. And they'll just go delete the old cluster. You know, like that's really not viable most of the time. So, you know, like, you know, and Kubernetes is pretty mature, but it's also, you know, there are some aspects of it like this that are pretty amateur, not amateur, that's the word, pretty immature, I suppose. So yeah, that's why it's so funny you asked that as the first question, because it's like, that's not a great, not a great experience on a great story right now. And I would love it to be better. I hope that we'll be able to come up with something.

 

Yeah, I guess what I was getting at,

 

No, it's totally fine.

 

I didn't mean to like, surface

 

Yeah,

 

the biggest

 

yeah.

 

pain point.

 

Hold still, I'm gonna poke you

 

But

 

in the eye!

 

what I

 

Ha

 

was getting

 

ha

 

at...

 

ha!

 

Yeah.

 

I'm going to get sold. I mean, more of what I was getting at is, uh, yeah, I'm trying on the Kubernetes as a,

 

Mm,

 

the defacto

 

sure.

 

deployment service, right? If we want to make like active deployment, right? Like should it be on

 

Yeah,

 

Kubernetes

 

right.

 

and

 

That's

 

why?

 

an interesting question though.

 

It is.

 

Cause I feel like if we have active deployment, you know, just like we have, uh, what active storage and you can choose cloud storage or local storage. You've got the active job and you can pick like sidekick or rescue or delay job or any of those. Yeah. It seems like we had active deployment. You, it would make sense to say, you know, Kubernetes or a VPS or.

 

Right. I

 

Right.

 

see what you're saying.

 

Or, or, or, I like that as an option. Right.

 

Mm-hmm.

 

could adapt onto a Kube or adapt onto something a little less painful setup than Kubernetes. I don't know.

 

for sure. I think that's also a really good question or a really good point to make. Like why Kubernetes? You know, why? Like, because I personally think that Kubernetes is the right target for something like active deployment. And the reason I say that is because, you know, your app is never just your app. Your app is

 

Mm-hmm.

 

obviously your app and your code that you know, you have in your app, but there's also a bunch of external stuff. So I mentioned before, Sidekick Workers, database, Redis, Elasticsearch, whatever. there's always a bunch of sort of peripheral stuff on the outside of your app. If all you needed to do was put your code on a server and say Puma run or, you know, bundled exec

 

Thanks for watching!

 

rail server, then, you know, this would be a totally, Kubernetes would be a terrible choice because it's way more complex than you need for something like that. But because there's all these external peripheral services that you need to access or not even, I wanna say services, processes that you need to also run and manage, doing all of that with CopAstronos doing all that with any other platforms, absolutely doable. But Kubernetes makes that just a lot more, a lot easier. And the way I talked about this in the RailsConf talk was if you are using Capistrano, then the primitive that you're working with is just a server somewhere. Capistrano uses SSH to connect to your server. All that it has to work with is what you've given it on that server. So that server may or may not have system control. That server may or may not be running AMD processors or you know x86 processors versus M1 processors, right? So there's it may not even have an internet connection. We don't it's it's just you know, you're you're you're given this Platform to run on but all it is is a server that has some software running on you don't even know or control what that is so From a tooling perspective like as a developer, you know a lot more about the server than campus rondo does You know that it's running this version of a little too You know, it's got these tools installed the campus runner doesn't know that stuff You have to basically tell it what what to do And it can kind of rely on certain tools existing, like there has to be an SSH daemon running, of course,

 

Mm-hmm.

 

but that's about all that it knows about your server. So from a Capistrano author's perspective, all that they can really do is let you run commands and you have to sort of specify what those commands are to a large degree. When it comes to Kubernetes, however, you have a much larger, much richer API that you can write code against. You can, for example, You can be totally confident that your server or that your platform can run Docker images. You can be totally confident that the networking between pods and pods by the way are just running containers. You can be sure that that's something that will just work, right? You don't have to go and configure that stuff. Well, you have to configure, but you can guarantee that it's there and that you can use it. So you have a much larger surface area of APIs to contact and to access and to do stuff with. Obviously, there are other tools that will do this, that will do this as well. But most of them are proprietary, right? So you could use render, but render's proprietary system, you know, would mean that you'd have to code specifically to render's APIs. Kubernetes is running, you know, is an open source project. A lot of these providers, these hosting providers like DigitalOcean will let you stand a Kubernetes cluster up. And that cluster is going to look exactly like a cluster that Lino would give you. So it makes it a much better target than just a bare metal server. of the richness and because it's going to be the same pretty much everywhere, that something like Active Deployment could target. Because it's so rich, that means that Kube can, for example, stand up a database for you. It can stand up a series of, it can set up a Redis for you, and it can use a plugin to stand up another set of pods that will be your sidekick workers. So

 

Thanks for watching!

 

without having to do really much of anything besides, like as a person who has a lot of is going to be using Kuby, go to a provider like there's lotion and say, get me a cluster, get that clusters ID, paste it into your config, and then you're off to the races. Like there's no additional messing around that you have to do. Right. And we are able to do that because it's targeting Kubernetes and because Kubernetes is such a rich platform and rich API. you

 

So let's say that, you know, QB starts to become the de facto standard, right? And people are like building on top of this. Like, do you foresee like, you know, kind of rails triggers into that process where say like, you know, the typical sidekick installation is, you know, gem install sidekick and then have some configuration somewhere that says where Redis

 

Right.

 

is. to be able to like just say, okay, I want sidekick and it will automatically do that for your Rails app or where does that divide lay

 

Yeah,

 

now?

 

that's a great question. So Kube supports a plugin architecture. So that's how the providers work, like DigitalOcean, Linode, they're just gems that you would add to your gem file and then you require those at the top of your Kube config. And then in your config, you can say provider, DigitalOcean, provider Linode. By the same token, you can also install like the Kube sidekick gem, require that, and then add plugin sidekick.

 

Thanks for watching!

 

And there's some config that you need to add, but that's documented in the gem, the gems readme. So your config initializers, psychic.rb, there's basically a block of code that you can just copy paste from the documentation. And that will then, when your app starts and starts to shove jobs into your queue, it'll just communicate directly with Redis automatically. And there's no additional configuration besides that that you need to do. So yes, there is, to answer your question, yes, there is a paved path for sidekick and there could be, I mean, you can imagine how much, how far you could take that, right? You could have a paved path for elastic search and for everything else that you wanted to also.

 

Yeah, that's cool. I mean, one of my. One of my biggest gripes currently is, you know. I experiment

 

Mm.

 

a ton, and I imagine like lots of people that, you know, are working with rails are experimenting a ton because there's so much new that changes and so much new to explore as you like start

 

Hmm.

 

diving in more. You know, how easy is it to say, like, let's say I have like a Linode machine or just as many apps

 

Yeah.

 

as I want to it. Is

 

Hmm.

 

it more geared toward a multi-node setup?

 

Hmm. Yeah, interesting. So I think there might be two questions there. So like if you have a bare metal server there that like

 

Yeah,

 

what you

 

that's

 

would normally

 

the idea.

 

deploy with Capistrano to, is that the idea? Yeah, right. So because Kube requires you to have a Kubernetes cluster, you would need to be running a cluster on that node, but there are like kind or KubeADM, there are ways to do that on a bare metal server. There would have to be, to get that to work. But it's definitely possible. And then the other thing too that Kubernetes offers is namespacing. So when you deploy an app using Kube, it will create a namespace for it and all of the pods, so the app and the psychic workers and all that are deployed into that namespace. And you could then deploy another app into that same cluster, which would just choose a different namespace. And so they'd be isolated from each other in that regard. So yeah, you could

 

I was going to ask about that.

 

wanted you to do it. Yeah.

 

Because what I'm looking at, and so this is interesting, I mentioned that I'm running the same code base for both Top End Devs and Podcast Playbook.

 

Mm-hmm.

 

And so when I deploy, I do cap production deploy, and it deploys it to Top End Devs. It does not deploy it to Podcast Playbook. And the

 

Right.

 

reason is because Top End Devs is getting more usage, before I push it to the other system. And so I'm imagining, yeah, that I might, or the other thing is, it's a platform that I also imagine other people may want to use at some point. And so

 

Right.

 

I'm liking the idea that, hey, you know, when I'm ready to have it deploy globally, right, it just deploys to all of the namespaces. But at the same

 

Right,

 

time,

 

absolutely.

 

if I wanted to go to just one app as kind of the testbed, then I can do that. it's simple enough to do instead of having to have

 

Right.

 

a podcast playbook environment config for the deploy and a

 

Mm-hmm.

 

production deploy file for the config, right?

 

Yeah, for sure. So yeah, I mean, you could always do like the multi tenant concept, I guess. But the other solution, like you mentioned, is just a deploy to like different clusters. And

 

Multitenant

 

you can absolutely

 

is such a mess. I've never

 

I know.

 

seen it done where people don't spend years trying to fix it.

 

Yeah, for sure. It's nice. And especially if you wanna truly isolate the data from

 

Yeah.

 

between customers, then having another instance

 

Which I definitely

 

is the

 

do,

 

way to go.

 

yeah.

 

Yeah, for sure. Yeah, so Kubi actually supports different environments. And so what you could do is potentially have a bunch of environments configured that you could deploy

 

you

 

to individually.

 

Is there a way of sharing sort of global config or global information? This goes back to

 

Mm-hmm.

 

Valentino mentioning, like you have to tell it where the Redis server is. You have to tell it where the Postgres

 

Right.

 

server is and stuff like that, right? So I stick that

 

Right.

 

in environment variables, but then I send the same environment variable to all of the things, right? So they can

 

Right.

 

all talk to the things. So

 

Yes.

 

is there some kind of secrets management that goes into Kubernetes like that?

 

There's, well, so first of all, you can specify that like shared configuration. So if you have a bunch of environments in your Kuby config, you can have a shared, like it's just a Lambda, essentially like it's instance

 

Right.

 

exact into each environment because

 

Okay.

 

it's a DSL. So you can have shared config. In terms of secrets, yeah, Kubernetes does have like probably the worst secret management. And this, I say this with, you know, with potentially love in my voice here, like there's a specific like object type in the the K8s API called secret. But all that it does is take your secrets and like base64 encode them. So like they're not

 

Oh, I feel

 

really

 

better

 

encrypted

 

now.

 

at all, right? I know. So, you know, the only, like if you have access to the cluster, then all you need to do is copy that string and like run base64 decode and you can see the secret.

 

Right.

 

There are certain providers will like hook into that.

 

Yeah.

 

So like AWS, for example, has their KMS service, their key management service, and you can tell it to automatically encrypt your secrets. Like when they go into the Kubernetes API, it'll just automatically go and encrypt those for you. And the same thing is true, I'm sure of other platforms. Kuby itself, like doesn't do any additional encryption. I guess we could

 

Okay.

 

add that feature, but it doesn't do any additional encryption currently. It will, one thing that is kind of nice though, as opposed to like it won't like Kubernetes will, or Kube rather will not turn your credentials into the secrets. It keeps your credential, like you know your credential, your encrypted credential store in Rails. It uses that, like it encourages you to store all your credentials in there and those are encrypted,

 

Right.

 

you know, using a much better algorithm than Base64. And so as opposed to like turning that into a secret, which would then get Base64 encoded, it instead just, you know, you copy that file up with your app, like you would normally do with

 

Right.

 

Capistrano or anything else. And then you just provide that Rails master key.

 

Yep.

 

And as long as the Rails master keys provided the Rails, we'll just look at that file and open it like it would normally do in development. So it doesn't try to do any secrets decoding and stuffing into a secret. It just copies that file up and then you provide the master key and it uses the key to unlock it.

 

Yeah. The reason I asked is because that's the other issue I've had with running the same code base in multiple places is yeah, the database strings and stuff like that. They

 

Right.

 

all have to be managed differently and putting that all into that in a secrets encrypt file in rails.

 

This is it.

 

It, it started to get to be kind of a headache.

 

Right.

 

And then I was using the same master key everywhere and I'm like, yeah, this

 

Yeah.

 

is not ideal. So

 

Yeah,

 

yeah.

 

for sure.

 

Anyway.

 

One thing I will say actually about database, like passwords and usernames and stuff, I mean, specifically passwords, those are the secrets, the secret part of connect to a database.

 

Mm-hmm.

 

Kube actually, because it's using, I mean, Postgres can do this too, but we actually, I might say we, the project, I wrote the project to modify it so that it uses CockroachDB now, which is like a lot more

 

Mm-hmm.

 

cloud native. And what I mean by that is it's sort of more designed to run in an environment like Kubernetes, as opposed to Postgres, which you're gonna have to massage And because Cockroach has like wire compatibility with Postgres, for the most part, it's a drop in replacement for Postgres. There are some slight changes, but both of those databases support connecting over SSL or over TLS. And so you can use a password if you want to, but what Kubi will do by default is generate a series of certificates for you. And then when you connect to the database, it's all over SSL and there is no password.

 

Oh right.

 

Yeah, so you don't even have to worry about having a password. If you're, if, if Kubi manages your database, it just automatically will connect and work via SSL or via TLS certificates.

 

That makes sense. So you just tell Cockroach, Hey, these certificates are okay.

 

Right, exactly. Yeah, like the Cockroach server has the private key, but

 

Mm-hmm.

 

the Rails app only has the public key, for example, and it will encrypt that, send it to the server, and the server decrypts it, and runs the query and returns it.

 

I've got a couple of follow

 

Cool.

 

up questions here.

 

Yeah.

 

Oh, I was gonna say, I was gonna let

 

Yeah, sure.

 

Valentino get a few more

 

So

 

in

 

two

 

here.

 

other things just kind of looking at like, okay, putting Kubi in use, right? Like, I guess I have like kind of a three part question is like, what are some of the things that you've seen Kubi kind of solve for you?

 

Okay.

 

Right? That maybe doing it a

 

Mm-hmm.

 

Another is kind of building on that is like, how does, like, let's say you have a completely separate team devoted to DevOps, whatever you want to call it, you know, does the Kube configuration kind of conflict

 

Yeah.

 

with people running manual commands in Kube control or something like that? How is that managed? And

 

Mmm. Mm-hmm.

 

I guess the last one is related to your plugins, which are really cool. third party plugins, how does that kind of system work? And do you have plans to like open that up to more like, you know, QB.install kind of setup.

 

Yeah, yeah, super good questions. So yeah, what does it solve is a good way to, I guess, I wrote them all down here, so I'll start with that one. For me, so like, as far as I know, there's only two apps that are currently using Kube right now. One is my dad's construction website. Shout out to masterbuilderconstruction.com. Yeah, right. And that actually started life as a PHP app and I converted to Rails It really exists only because I needed a test bed to run Quby stuff with. The other one is the storybook. So I work on the design infrastructure team, or design engineering team at GitHub. And we work on Primer, this design system, and Primer view components, specifically. And those view components, there's a storybook, which is this cool design tool that you can use to

 

Mm-hmm.

 

preview your components and whatnot. So it uses a Rails app to render the components. And so that's also deployed with Kube into Azure Kubernetes service. So there's two apps that use it. And for me, what it really solves is just like I just went, I spent so long, like I've stood up numerous Rails apps in my career, either professionally or just on the side. And like every time I do that, I had to reach for something like Capistrano or I had to use Heroku. And there's just limitations to each of those approaches. Like I thought we talked about Capistrano

 

Yep.

 

at length. And Heroku is phenomenal, to I think 10 individual web apps on their free tier. So if you wanted to go and launch that 11th app, you'd have to kick one out before you could do that. Otherwise you'll end up spending money and I didn't want to spend money on it. Which is funny because like with Kubernetes, like, you know, there's no way to not spend money on that. So what I was looking for was a way to deploy something that I had more control over, but that I wouldn't break the bank to stand up, you know? Like Heroku can get really expensive if,

 

Oh yeah.

 

even if you just do a couple of really basic, like even if you want just a few more database I think it limits you to 100,000 rows or something. Even if you want 100,001 rows, you still have to pay. It's a pretty steep, it goes up really quickly.

 

Mm-hmm.

 

And I found that I could actually get basically more freedom by spending the same amount of money. So you can run, I think on Line node right now, my dad's website is hosted for about $25 a month. And it's just one node and there's a load balancer and it all works really well with Kubi. And there's no sort of, I don't have to worry about the additional overhead of paying. I'm never going to have 100,000 rows in that database, but if I do, I don't have to go and worry about increasing my account limits or whatever. I can just increase the size of the disk that it's on and be done.

 

Yeah.

 

It solves those problems. What I'm hoping is that it will eventually become, because I think that my real goal behind this is not so much to stand up my dad's database or whatever, my dad's website. My real goal is to prevent people from getting that point in their Rails journey and realizing that they either have to spend money or have to struggle setting up Capistrano or whatever, you know, or have to bump another app off their, you know, free tier in Heroku. I want these developers that are coming up in Rails and coming up in Ruby to not get stuck at that step where they have no chance and no options to deploy something or that Rails doesn't provide for them, right? So that's what I want Kube to be is this plugin system and this thing that you can just plug into your app and suddenly you're like off to the races, right? So yeah, that's the major goal is to make sure we don't lose companies and juniors and stuff at the step where they like make their app and then they can't deploy it. Okay, and then your next question was, does Kubi's config like supersede kube control commands? Like what if you run a command with kube control and then that like somehow, you know, conflicts with your kube config? That's a good question. I mean, you can definitely do that, right? You go and, for example, mess with the config. is that there's not, like you can go and mess with that config manually. You can go and apply, for example, a different YAML file or editor resource directly in your editor that you could, that your kube control command could start up for you and save it back and then mess things up. Totally true. One thing that's nice about Kubernetes though, is that it's sort of, if you wanted to go and sort of fix that, or if you wanted to, like you made a mistake, you could simply deploy with kube again, that you just edited with the one that could be generated. And so that would hopefully fix any of the problems that you introduced by manually editing things. So that's kind of a double-edged sword, though, right? Because it's really just clobbering all the config that you already entered. If you wanted to persist that, if you wanted to make a change that would persist on multiple deploys, you would need to make that change in the Kuby config.

 

Right.

 

And Kuby uses this other project called kubesl to generate Kubernetes resources. There's really no part of that deploy process that you can't monkey with if you want to I had to do a lot of that actually for the for the the primer storybook So yeah, so I would recommend that you not run, you know random kube control commands that are making changes to your resources And instead go in and modify your kube config to tweak whatever you want so that it's a persistent change

 

Yeah, but that was the

 

Um,

 

same story

 

yeah.

 

with things like Chef and crap like that too, is, you know,

 

Yes.

 

it would generate your config files and then basically just stick them on the server and it wouldn't even check to see if something was there before.

 

Exactly, that's totally right. So, and it could really devastate things if you're not, like it was making changes that, you know, you weren't expecting or that weren't codified somewhere, you could really get

 

Yeah.

 

into big trouble. Yeah, that's true. Okay, and then to answer your last question, third-party plugins. So right now there's one third-party plugin. So anybody can write a plugin. I have documentation for that on the getcubi.io. You can make your own plugins. There's one that I know that, so all of the plugins except one have been written by me. get Kubi organization. Yeah, but there was a great article published by the Evil Martians, Vladimir Demetyev, where he talked about deploying an app with Kubi, and he made some really interesting suggestions as part of that article. And so I think the Evil Martians are the guys behind AnyCable, and they wanted to get AnyCable working with Kubi, so they wrote a plug-in for it that you can, I think it's just EvilMartians slash Kubi-A-AnyCable, and if you add that to and it will automatically stand up like the AnyCable Go service and

 

Oh, that's

 

just

 

cool.

 

wires everything up for you. So it's a really good example of being able to take something that would normally have taken a lot of effort to get running,

 

I'm gonna have to.

 

and you

 

That's

 

can just

 

great.

 

drop a plugin in and it just works.

 

I'm gonna have to play with that.

 

Yeah, it was fun to see that happen.

 

Yeah.

 

Yeah, for sure. I mean, it's again, that's really because of the power of the Kubernetes platform. Like, imagine trying to do something like that, you know, in Capistrano or, you know, even in Heroku, I guess it's

 

I'm

 

all

 

get-

 

possible, of course, but it would be I think it's much easier to do that in those other platforms.

 

I don't, you know, part of me is, I don't know if I'm like, it's the longevity of, of me being, you know, a seasoned developer that I'm just used to the, you know, uh, orchestration at this point,

 

Mm.

 

or some of the, some of these skills that maybe if I was just starting now, I would just overlook

 

Mm-hmm.

 

because other people do that or there's other tools, right? Uh, so it's kind of hard to tell where it's

 

Mm-hmm.

 

is

 

going

 

in.

 

to go. It's what I'm saying. Uh, but it definitely, I, interface

 

Yeah, for sure,

 

of

 

for

 

Kubi.

 

sure.

 

As a configuration, it did make it feel easier to deploy, I will say. Because I similarly have been down that Capistor on

 

Mm-hmm.

 

a path where I have a bare metal server and I want to push it and something isn't there, right? That it's expecting and you have to figure out what it is. That pain just

 

Yeah.

 

sucks

 

Mm-hmm.

 

so much time away that, you know,

 

For sure, for sure. Yeah.

 

which even though that's probably not the best thing, uh, you still would save me time, you know.

 

Yeah. Right, right. Yeah, no, totally. Yeah, you know, that's actually a really good point that like I think a lot of the DevOps kind of revolution that we went through was realizing. Well, I don't want to say revolution. There's been there have been several stages of DevOps, I think that we've all sort of experienced. And the first one was like, oh, I can I can code up a like I could write a script, but it's it could be a chef script or it could be a bash script. that will provision my server for me. And then I can run that on the server every time I create a new server.

 

Thanks for watching!

 

Oh, that's gonna save me so much time. And maybe on the first one it does, but then the second one it's gonna blow up and something's not quite the same as you remember from before. So that was sort of the first wave. Like we can codify these rules into a script or a chef cookbook or whatever and apply them everywhere. And that was pretty great actually for a long time. What we I think discovered though after that was that it's often a lot better to just have everything be ephemeral. You don't want to lose your data. But like you talk about deleting a kates cluster and bringing another one back up, that often is just a much easier

 

you

 

solution than like trying to debug the existing one. And because

 

And, you

 

it's

 

know,

 

so ephemeral,

 

I even

 

I could

 

think

 

just

 

of

 

delete

 

it

 

it

 

too,

 

and make a new

 

like

 

one and move on with my life.

 

stuff

 

Mm-hmm.

 

that you come back to after years, right? Like I have all these old apps that I have up that, you know, I don't want to upgrade or anything because they're just, you know, they're so ancient. And I was like curious, you know, about something that I had worked

 

Right.

 

on and I wanted to try and get it up again, just see what was working. I couldn't. I was like, well, I just said, I'm not going to do this.

 

Yeah. Yep. All

 

pretty easily,

 

right.

 

you know, I feel like that could take out a barrier. It's definitely a pain point

 

Yeah,

 

of mine that

 

totally.

 

I still have.

 

Yeah, really good point. Like the bit rot that often like sets in on on these older applications. Yeah, absolutely. And like Docker is the thing that really, I think makes that easier. Kubernetes doesn't really help you in that. I mean, it would because you could still launch it or deploy it or whatever,

 

Yeah,

 

but

 

but then

 

the

 

I'd

 

Docker

 

have to make

 

image

 

a Docker

 

is really what

 

image

 

like

 

for

 

would

 

those

 

save you.

 

old apps.

 

Yeah.

 

Right. Totally. Yeah.

 

Good luck.

 

Yeah, man.

 

Cool.

 

There's actually, I mean, Ruby, so the Ruby official Ruby Docker image has, I think versions going all the way back to like 2.2, I want to say, maybe even 2.0. So you can go back pretty far in time with those images.

 

Yep. All right, well, let's do some picks. I think we've pretty well covered the topic.

 

Yeah.

 

Sure.

 

Valentino, do you want to start us

 

I

 

off

 

just

 

with

 

came

 

picks?

 

across this article from the guy that's been working on all the improvements to IRB. Was it Stan Lowe? He has this article on from Bye Bye, Bye Bug to Ruby debug. It's really cool. It outlines kind of all the pain points from Bye Bug and kind of what's new really cool to see all the new features that are coming out of there. And my other pick is Keychron. I have this new keyboard. It's wireless. And I haven't had any issues with it. It's mechanical. And I don't get keyboards that often. So this was a huge, huge win for me.

 

Nice. All right, I'm gonna jump in. I usually do a game board pick or game board pick. I must be tired. A board game pick. The one I'm gonna pick this time, it's card game, it's called Quiddler. This one's been around for a long, long time. So a lot of people may have played it. Effectively, what you do is you have a hand of cards, you try and make words out of it. When you've put down all the cards in your hand, kind of gets a shot to put down what they've got and then you tally up the points you get bonus points for having the longest word or the most words right so you can put down two words anyway Yeah, but that's pretty much the game. It ranks on board game geek at a 1.43, which means it's on the simpler side. I mean, I basically told you how to play it. So, you know, and you just play a number of hands starting at three cards and going up to however many cards. I like board games because I tend to win them. But yeah, it's a good family game. And so yeah, I'm gonna pick Quiddler. trying to think what else I've got here for picks. I'm ramping things up on the Meetup side. So keep an eye out if you go to topendevs.com slash Meetups or if you scroll down, it should show you all of the events we have coming up. But yeah, definitely check that out. I'm also thinking about adding a function. We're using Riverside to... to kind of do the show live or to do the show among us. And I haven't been posting the videos, but it does have a feature where people can join as audience. And so you could kind of see us talking, you could see my messy office. And so I'm thinking about putting all of the shows, live recordings on there, so if people wanna come in and participate in the chat that they can. But yeah, I'm really looking at that Rails Remote Conf is coming up, CFP still open. I'm trying to think of what else I'm gonna pick. My wife and I started watching a new show, and so I'll pick that, and that'll be my last pick. It's called The Lost Symbol. It's based on Dan Brown's book. It's on Peacock. I remember back in the day you'd say, it's on channel five at six p. Not anymore, it's on this streaming service, it's on Peacock. I think my wife picked up the Peacock Plus subscription when she wanted to watch Olympics. Then we held on to it because I wanted to watch Yellowstone. Now we're watching Lost Symbol. They've got a ton of stuff on there just like all the rest of them. But yeah, this one's pretty good. It's based on the book. I haven't read the book in so long. I can't tell you how closely it's sticking to the story. But it's got, what's his name? Robert Langdon? And, you know, I think the characters all have the same names at the very least. So anyway, it's been decent. It's not riveting to me like Yellowstone was. Like Yellowstone, I couldn't quit watching it. But it's nice to just sit down and, you know, watch a show with the wife. And this has been a good show. So yeah, so I'll pick the lost symbol as a pick. All right, Cameron. Thanks.

 

Well definitely plus one to Quiddler. That's one I played before. It was pretty fun. Lost Symbols is interesting because I feel like that wasn't... Did they make that into a movie at some point like a couple years ago? I want

 

I don't

 

to say

 

think so.

 

I got...

 

They did Angels and Demons and they did the Da Vinci Code.

 

Oh, DaVinci cut, right, but they haven't done Lost Symbol. Okay,

 

I don't think they did

 

cool.

 

the Lost Symbol. The Lost Symbol, the book, wasn't as good as either the other ones. He's done

 

Yeah.

 

four or five books that

 

Right.

 

I've read, and Angels and Demons and The Da Vinci Code are definitely the better books.

 

Yeah, I've read all of them as well. It's like one of the only authors that I read anymore. But, you know, I've been told that I have poor taste in literature, but I think they're really good. So I was hoping that maybe the Lost Symbol book was, or series is good too. Um, so.

 

So far, we've watched like three or four episodes.

 

Okay, okay, cool. I might have to check it out. So yeah, my picks are gonna be, I just have two picks. One is view component. So I work on the design engineering team, as I mentioned at GitHub. And one of the projects that we work on is the view component framework. And view component's a really, I would say, awesome way to clean up your views, especially if you have logic in those views.

 

Mm-hmm.

 

I know that Joel Huxley, the creator of View Component, has been on this podcast before So at this point,

 

I am

 

I

 

addicted

 

think probably most

 

to

 

people.

 

them.

 

Oh, nice. That's good to hear.

 

I use them

 

Yeah,

 

all the time.

 

that's awesome. Yeah, we really there's lots of adoption and I just, you know, wanted to pick it because it's like, I think maybe one of the best things to happen to the Rails View layer like maybe ever. And then my last pick is going to be for Apple AirPods. I'm just a huge fan of AirPods. They work

 

Mm-hmm.

 

super well. I've dropped them like a billion times and they still work. And they're a little expensive, but they're absolutely worth it. Pro AirPods. So, you know, if you're looking for a pair of really, I would say, pretty good quality, durable, works automatically with everything I have that's Apple based. You know, if you want something like that, then definitely get the AirPods to try.

 

Yeah, I haven't tried the AirPod Pro. I've always just gotten the older AirPods. In fact, mine died and I recently got new ones and I went and got, specifically got the old version of them just because I like them

 

Okay,

 

so much.

 

sure.

 

But they, yeah, they stand up well, they

 

Yeah.

 

pair with everything. And it seems like I have to replace them every like three or four years. And so, I mean, they hold up really, really, really well.

 

Yeah, three or four years for headphones is pretty good, I think.

 

Yeah.

 

For like in-ear headphones, yeah.

 

Yeah.

 

Cool. Well, thanks guys. It's been a real pleasure.

 

All right. Yeah, well, we'll wrap it up here. Till next time, folks. Max out.