Hey folks, welcome back to another episode of the Ruby Rogues podcast, the Sweet Conod Panel. We have a Yushnawatia Hello, Hello, also a Valentino stole in.
Now.
I'm Charles Maxwood from top End Devs and this week we have a special guest. We have Robbie Russell from Planet Are Gone. Robbie, do you want to I don't know. I'm like, where do we even start? You know, O my zshell or what's.
A amazy show?
Now? Yeah? Hi nice, thanks for having me on today. Good morning, Good afternoon everybody. So, yeah, I run a company called Planet Argon. We're a soccer consultancy. We've been around for twenty almost twenty three years now, part of the Rail's ecosystem for just over twenty years now, and we help companies with existing rails applications make them better and more maintainable.
We do a lot of consulting work in that space.
And I also so I'm known for having created O my zshell Once upon a Time, which is an open source configuration framework for z shell if that's something you like to use on the command line, and an open source contributor for about twenty five years. I'm also the host of the Maintainable Software podcasts, where I interview people about best practices when it comes to taking care of older legacy applications across a lot of different frameworks and
tech stacks. That's not a rail specific but there's a lot of Ruby and rails related contact because that's my orbit that I exist in, and I also play guitar in an instrumental rock band called the Mighty Misula.
Cool. I didn't know about the rock band. I admired you from Afar for a long time for all the other stuff. So yeah, it's exciting to have you on. We brought you on to talk about I got an email from you. I think I'm on an e mailing list somewhere, and it basically said the Stimulus JS replaced Here we go. Stimulus has dethroned reacts as the most popular JS library for rails apps. And so then I went and looked at the survey and that that was
kind of interesting. I want to ask you about all of the other things though, so sure, uh yeah, let's go ahead. And I just want to get a little bit of background. I mean, I use on my z shell and it's oh my helpful and so I'm curious what the story is behind that. And then I'd also like to talk a little bit about Planet Argone before we get into survey.
Yeah, yeah, that sounds great.
So oh my DHL. I first, really, we celebrated fifteen years that I since I released it back and I think it was August now, it was fifteen years ago, so fifteen and a couple extra months now.
I have been using ZHL for a couple of years.
A lot of peers in the Ruby ecosystem at the time, we would all share a little configuration ideas for how to use VHL and optimize it and get was kind of a new thing at the time, so doing things like having your giit branch in your prompt was kind of a really new cool idea and I think it helped us. I think it was this a good timing overlap with trying to wrap her head around like local branches at the time. So but basically I had compiled this crazy z shehell configuration file that half of it
I kind of understood half of it. I probably didn't because I was just copy and pasting and trading things with my friends over IRC channels or old websites like pasty, which was kind of like a gist before get up existed.
And I would be parent pargnering with one of my coworkers at my company on a thing, and we'd be on their computer and I would get frustrated because all of my muscle memory wouldn't I remember how to do how to fully write out of the commands because a lot of shortcuts and aliases and little optimizations that I
had added to my own configuration file. So I was I found myself just feeling frustrated with myself, and so I'd be like, hey, why don't you use zshell and just copy my configuration file and then and then I'll show you how you can be quicker at the command line, as I feel like a lot more efficient now. And so I would kind of encourage my team to do that, and a few people would take take me up on that, but several people didn't like one person, particularly named Carlos,
on my team. He was very resistant to because he didn't he wanted to understand what the config file did. And I was He's like, well, walk me through it, and I'm like, I honestly can't because I don't really understand a lot of this gibberish z Sholl sent text does and so we kind of, you know, we butted heads a little bit, and he wouldn't take me up on the idea. So I decided one weekend, I'm like, you know what I'm gonna I'm going to try to document my config file. I'm gonna go through and just
add some comments. I'm going to like look up the documentation in the z shell syntax and I'm going to try to understand this. And then as I started doing that, I started like refactoring it basically and moving in and I'm like, well, this is like a really big file. What if I made I should probably use some version controls, So I'll put this in and get repository. And I started making like separating out this big config file into
several smaller, messy config files. And then I slapped a name on it, and I called it on my seashell because it was a playoff of another project that I had worked on a.
Couple of months before, or with a different coworker.
We didn't really put a lot of thought into that either, but I created like a read me with an install guide, which was basically like a get clone of this repository that I created, and then and then you could use my knfig file, and so I felt like I just elevated. But that was like maybe a handful a few hours worth the work of cleaning up that file and turning
it into this new repository. Threw it up on GitHub, and then I dropped that link I don't remember if for using campfire or some other chat tool back in the back in two thousand and nine, dropped it in our team's chat. Everybody installed it on Monday victory I won. Everybody now had my canfiic file, so I would go to the computer and I would all the same things.
So that was my goal, was just to have everybody in my office kind of have the same ISSU configure, so that I could show them how to feel like a superhero and the command line, and I wouldn't have to remember how to like do everything like write out all tho syntax for a lot of the obscure commands
that we were running. But then, so the thing that a lot of people know about owens the shells that it comes with a lot of themes and tons of plug ins, and like none of that was remotely on my dea my was it even something I had considered? That next day, one of my co workers, Gary said, how do I change the colors? I was like, why would you want to do that? My color choices are perfect? And I was like, well, here you can go in this file. I moved like I think I had like
colors or prompt file configuration files. I'm like, you can change the colors in here, and here's like the syntax
for that. So we started doing that. He started making changes, and then other team members wanted to add contribute their own little shortcuts and little functions and aliases as well, and so we were kind of working together on this, and Gary couldn't do a get pull and get pushed cleanly because he had changed the file, you know, and get conflict, and so we're like, so we're like kind of like, well, so we had like stash it and
then pull the changes and then reapply them. And I'm like, well, this doesn't feel very sustainable because then another co worker is like, I want to change the COLO and so I was like, well, what can.
We do here?
And I was like, oh, I know, I'll just move my prompt file into its own thing and call it Robbie Russell.
We'll call it a theme. These are themes.
Gary has his, I have mine, Carlos can have his, Allison can have hers. And so it created the concept of themes, which became like a configuration option. And so then I met I mentioned it on my blog and Robbie on rails back in the day, and so it's mostly within the Ruby ecosystem. And then about a month later we started getting contributions. But about and a lot of themes started popping in by other people as well, so that.
Was kind of like a fun thing.
I suppose, like, hey, we have this real repository.
We can inspire each other.
And about a month later someone reached out and said, hey, this is really cool, but I'm a Python developer. I don't need all this Ruby stuff loaded up when I when I run this, Like I want to use the prompt stuff with all the get stuff, but I don't need all the Rails and Ruby stuff that you have loaded.
So I was like, oh, that's interesting.
I don't want all that pie stuff Python stuffloaded when I use it, so maybe we'll all these plugins. And so I moved all the Rails stuff and Ruby's stuff into its own thing, and we had Python stuff come in, and then that just opened the floodgates for other people be like, oh, I got this thing from my framework, or I had this other tool that I'm only using.
And so.
This stuff kind of organically evolved as the community started using it and pitching ideas, and I was like, well,
here's a way to kind of organize that. We'll just throw these in different directories with different kind of enable these things, and that just kind of snowballed into this thing that's kind of evolved over the last fifteen plus years where we've had several remember the number of I think we've had, Remember how many couple we've had more than a couple of thousand contributors directly to the core project contribute code, and it's one of the most like
starred projects on GitHub and it's kind of wild. But I don't make any money with it. I sell stickers and T shirts. That's fun. But it's always been this kind of like fun, little open source thing that I can occasionally spend some time thinking about, but it doesn't occupy a lot of my brain space. Despite how wildly wide ranged in popular it has seemingly been.
That's awesome. I love it. Yeah. I also want to just talk a little bit about Planet Argon. You guys have been around for a while. Was this before or aftermyzshell and before?
Yeah?
Yeah? Story with yeah how that got started?
So I actually started planning Argon I see back in two thousand and two as a what I would because I was had a day job and I was like, I want to do we work with I worked at a company in some software development and we were uh that company was a dot net shop, and I was really interested in open source, and nobody at larger companies was really hiring open source technology people that often, and
so I love PHBA. It was really it. Had co founded a Linux user group here in Portland, Oregon, and so I was already kind of doing a lot of fun open source stuff, and so I was like trying to trains like, Okay, I do this net how do I do this in PHP? And then I started like, you know, maybe I can get some freelance work on the side, And so I decided to incorporate that as
a plan Argon. Thought I would make it sound like I'm bigger than just me, and it was like me and then my partner at the time, she was a designer, so we would. She would work on web design stuff and I did a lot of back end development, so we collaborate on stuff. So she had her company, I had mine, and so we so I was like, I'm gonna call my planet Argon, which was a reference to a fictional book or a fictional place in a Tom Robbins book called Still Left with Woodpecker, which is where
redheads came from. So I had nothing to do with anything. It wasn't some clever idea of gases or you know, the scientific chart there. It was literally just like a it's me, I have red hair, plane ragon, goofy little thing. So I did that for a couple of years, doing like side projects. In two thousand and four, I quit my last job to work full time on Planet Argon,
just as a you know, freelance insultant. And then and beginning of two thousand, late two thousand and four, begin two thousand and five, I got introduced to ruby and Ruby on rails and started doing that.
In two thousand and four, beginning of two thousand and four.
I started blogging as robbyond Rails and so this was five and a half years before Always You Sholl existed. I was part of the Rails ecosystem and doing stuff, so I think always sholl Will just kind of culminated it out of that community. So yeah, it has been around for a while. What we work on a lot now. So back then, it was a lot of like new startups wanting to use Rails because it was kind of
like this new hot thing for projects. So we learned how to basically went from that freelancer space of me working on by myself with my designer partner at the time, and to all of a sudden, like some really large projects started coming our way that would take more than me to be able to do it. And so one of the first services that we had was offering hosting services to rubyond Rails developers because there wasn't a lot of affordable hosting options unless you spun up your own
BPS or something. So I had been offering post rescuels hosting for developers and like PHP five development or environments for hosting because I had a lot of experience with like writing servers and stuff like that. So that was part of our services early on, was posting, even going back to two thousand. I think we started doing that in two thousand and three a site for a lot of the projects because i've it then host those projects.
So we were one of the first companies in the Ruby on Rails ecosystem to start offering hosting at kind of like an affordable price point, and we give people like shared hosting environments and made that kind of work. And then so that allowed us to broaden our exposure in the community early on. And then but a big part of what we were trying to do is just focus on developing sort of projects and stuff like that.
And then a couple of years into that, we started getting approached by companies that said, hey, we had a couple of freelancers build this app for us this last year. They're no longer available, they got full time jobs. Some morals, can you take over these projects? And one of the great things about Ruby and rails was that it was
there's a consistency between projects. So we found ourselves being able to like jump in quickly to existing projects and that became our niche over the years that now we quite essentially take over projects that are for companies that don't necessarily need to have two or more full time software engineers on their team in house, and so their other option is maybe having like a freelancer or two, but then maybe they do that, but the freelancers kind of come and go, and they're like, we have to
kind of restart this process a lot. So we end up owning a lot of projects where we're the primary development team for like five ten years with some of our clients, some of them over ten years. Now we're their dev shop, but we're maybe doing like eighty.
Hours a month on those projects.
You know, it's kind of like a but we're maintaining those things for the long term because they don't necessarily they're not trying to become a company.
It's like an application that helps fulfill part.
Of their business, but it isn't the business.
So like there's a lot of.
Those types of applications that exist, so we're kind of well tuned to come in and own those types of projects.
But then we also do a lot of consulting and coming in with companies that have their own engineering teams on helping them unblock themselves when it comes to like there's been a lot of turnover in those environments and maybe some of the original developers have you know, left, and some of the new developers aren't sure how to like make choices about, Hey, we're still running on rails four. We would love to get to seven, eight, but how
do we get to five? And how do we kind of navigate this and what frameworks and front end things should we be exploring now, And so we try to help come in and help coach teams on how to navigate some of that stuff and cleaning up techno debt and deal with overdue upgrades, performance improvements, stuff like that.
So that's another part of our business as well.
Nice okay, well more, Yeah, maintainable podcasts.
Yeah, so maintainable podcast just recently recorded my tuneth episode of that. It's an interview style format visions And one of the things I set out to do was I felt like there's always been a lot of good quality conversations around what's going on new in the software industry. New people always like talk about new stuff, and I was like, but a lot of software developers experience is showing up to a job where things are already there, things are already in motion.
And I think as.
A industry we've done ourselves to disservice by branding ourselves as being these like creators, makers and like, but reality, most of us are actually mending and taking care of existing stuff and trying to just make it a little bit better today than it was yesterday, leave things better off,
and like, that's good work to be done. And I've just seen a lot of developers over the years struggle to kind of like change like reframe that because I think we've but anyways, so I thought, I thought it would be interesting to have conversations about what it's really like to work at project on projects day in and day out that have been around for a really long time, and how to make incremental improvements because that stuff is hard and there's a lot of people dynamics, there's technical
dynamics at play, and so I wanted to just a catalog a lot of conversations that I thought would be relevant today but also in ten.
Years, twenty years from now.
I don't feel like these are conversations that will date themselves. So I'm trying to be very intentional about having conversations with people about how they navigate, how they've overcome, or sharing some of the painful stories about like yeah, we tried to do rewrite and that blew up in our phase.
Because I'm a big.
Advocate for not rewriting unless it's the very very last possible step you can possibly do. So I'm always like this, there's got to be a better way to think about how your approach to software projects rather than just dreaming that one day we'll finally get to rewrite this thing and then it's all going to be better. We will never have all these problems that we have today.
Which is complete bullshit.
So right, cool. Well, I have to say I've listened to the Maintainable podcast for a while and you always have terrific people on that make me think about how I do it.
So that's great, I have It's it's also just a good excuses get to have conversations with people that I admire on a regular basis.
I'm like, this is that's my favorite part of it.
Awesome. All right, well I'll quit fan boying and uh, well we'll we'll talk about the survey. So yeah, yeah, so do you want to just explain I'm always curious. I used to just be like, all right, well, let's just get into the meat. What's in the survey, right, And I think that's important, but I like to get
into the methodology a little bit. Right, like who who did you reach out to, how did you market it, what kind of people did you expect to take it, and and that kind of thing, so that we can get an idea of, Okay, this is the community it really reflects.
Yeah, yeah, that's a good question. So just for some historical context, the survey, we've been running the survey as long as always You Show has been around. So the first time we did it was back in two thousand and nine, so I think we've done it eight times now. Pretty much has been every other year, except for I think for the first couple of years we did it
like every year. But the original version of it was we wanted to get a lay of the land of because we were part of our business was doing hosting. Was like, how how is the ecosystem changing in terms of how people were thinking about deploying and hosting their applications because we were providing those services and the cloud services kind of this new thing, and we're like, is that where everybody's moving? Should we get out of this
part of the business. We ended up using that survey result that first year to decide to sell that part of the business off, and so we're like Okay, we're at we're not gonna be.
Able to keep up.
Let's just let them I'm done going to the co location and stuff like that. So we use the survey to make a business decision, but we decided we publish all the results for everybody make it because we were like, there's a lot of other interesting details in there around like what their party services people are using, and like we're using.
For error monitoring or performance tracking.
Things are just again and get a sense of like, well, how other people are doing because people can go online and ask those questions you know, in IRC chat conversations back in the day or some forums or stack over floor or whatever, and I was like, we kind of wanted to just like let's get a broader range of people. So we've been doing this, you know, every other year
since then. So this last year when we did it, our typical approach has been one reach out to people taken in the past, and so a lot of those people came to us from social media, following us on
different blogs and stuff like that. Reaching out to the mailing like the Rails, Rails Talk mailing lists and other groups that were you know, we're around at the time, but So for this last year, we did put a lot of energy into working with the Rails Foundation, in particular Amanda there and so uh, she had approached me the year before when she first got hired at the Rails Foundation to talk about the survey. She actually that was the first time I actually spoke with her about it.
Was she reached out and said, Hey, I want to talk about the survey and the Rails Foundation. I was like, Oh, no, they're gonna They're gonna start doing this themselves, and I guess we're no longer going to get to do that. That's that's what I was preparing for, Like, I guess we're kind of out of the business of doing this, and it's a lot of work to run the surveys and stuff as well, So it wouldn't be the worst
thing in the world. But through that conversation, I was like, Oh, they have very different things that they're looking for than we do. But what we did decide to that we
would go to the Rails Foundation. So they took that to the board and be like, what sort of other topics and questions might they the other Foundation members like, you know, shopifys and doctimity and companies like that might be interested in hearing about the ecosystem right now, and so we we got some new questions and topics and
a lot of that came up. So we ended up adding a lot of new questions related to education and like how people are learning about rails or how they're what type of content are they consuming to level up as developers, and is the assumption that video stuff is the future actually resonating with the majority of developers, So that we can get into some of the stats there.
But in terms of the reaching out to people, it was a lot of hitting the social media as I emailed everybody that I could, you know, I had reached out to in the past, and to have anyone that I knew that's written books in the last few years about Ruby or rails related themes, or people I've interviewed that happened to be part of the ecosism them like reached out to them, emailed them like, hey, can you blast this to your group or your mailing list, anyone
that runs a mailing list. So we have like a big checklist of places that we reach out to, but we do want to make that as broad as possible, so it's not.
It's not just like maybe.
One company that's like Shopify drops it in their internal chat tool and then it's just like half the you know, the people are just Shopify employees filling it out and all the data looks the same.
So so and.
So I'm always worried that that's going to be a thing because it wouldn't take a lot for like something to drastically skew the data when we've got I think we had a little over twenty seven hundred participants, which is the most we've ever had. A lot of people want to fill out a sixty question survey, you know that often, so it takes a little bit to go through that process. But but that's where we're able to end up. So that answer your question enough, I suppose.
Yeah, yeah, I think so. I kind of want to pull Valentino and I use it in Did you guys get a chance to look at the survey? And I'm curious was there anything that stood out to you because I don't know which section to really start with why. I have some ideas, but I want to hear from you guys.
Yeah, I think I looked at at when the results first came out because I'm fairly sure I actually did fill it out, and I can't remember whether I did, but I'm like ninety nine percent sure that that I did fill it out. A couple of things that cut my One was obviously the fact that stimulus d throw and react, which made me quite happy because I know to react.
That's how you realize that.
And yeah, the other thing I found quite interesting, purely from a selfish point of view, was how people learn Drew Andrells, because obfullly I've written a book as well, so I found it quite interesting to just see how people learning. And it's interesting to see that more people kind of watch videos and tutorials rather than read book or something like that, because yeah, I guess horses for courses and stuff, but on I prefer text based rather
than video. But it's it's always interesting to know like what other people are preferring, especially if you're trying to sell an educational product. So those are a couple of things that kind of I found particularly interesting out of the results.
Quick quick thought on that one when it comes to like the I think that's an interesting thought there around Like you read books, I skim books.
I'm not.
I think I'm actually slightly dyslexic, and so I'm not. It's always been really difficult for me to get through a lot of text based things necessarily. But one of the other questions we did ask so it was like what types of education and content helps you learn most effectively? And video stuff was not It's like the fourth I think it was like tied with books.
So most people said that they find blog posts.
And like the Rails guy, it's to be the most effective way to learn.
But they're consuming a lot of videos.
So it's like it's is there are they learning from the videos or are they just spending more time watching videos and because it's an easier way to consume that information. Maybe I don't know, but video is an interesting one, but I don't know. Again, this is what the people are kind of reported, so it's all they're all really closely kind of aligned in the stats as well, So like there was no I think huge prizes to me there, but otherwise people saying that like working on you know,
the documentation and things like that. So which is I think A good good thing that came out of this was like the the Rails Foundation, like Amanda them, they had I know that they.
Were working on a number of projects related to.
Video content and the new guides, like redesigning the way that all looks and revisiting a lot of the content there, and so there's a lot of energy trying to be on like let's do video, let's also do this. We kind of like have to come out of from different persons because there are just people do learn different people learn differently, and so it's like, how do we make this this as inclusive as possible.
Yeah, I'm looking at that question now about learning most effectively, and that's interesting. I wouldn't have expected that that mismatch there, But I guess like for me, we're personally with videos, I tend to zone out sometimes and then I'll come back a minute later and like, Okay, crap, I've forgotten to rewind and watch this again. And then you can't command f a video. So that those are my two biggest gripes.
That's true, you can't. I mean in the same way like I was reading a book last night and before I went to sleep, and I was like, got two pages and I'm like, what did I just read? I have no I've seen the words. I don't know what I just read. So let me start that again. But
you know, it's interesting. Live streamers came two percent of people find that the most effective way to learn, or or podcasts, and so our podcast educational or they media consumption or you know, it's this kind of like auxiliary information. But maybe is this an educational platform. I don't know.
I think it depends. One other thing that I wanted to point out was that I think a lot of newer folks are going to lean more toward video casts and books and maybe the rails Guide some I think as you get more advanced, you start looking more at the blog posts and documentation and maybe podcasts to just give you kind of here's what's the latest thing that's
out there. That that was kind of what I got out of it, And so I think you had a lot of experienced folks that they don't need as much of the walkthrough on some of the stuff that's out there, and maybe they're reaching for the documentation and stuff instead.
I feel like this is one of the hardest categories to extract something meaningful from the survey, right, because like I feel like learning, like you do kind of like pick a variety of different things to like build up your learning material and maybe different ways that you do you don't think about and how much they impact you too, Right, Like I remember like really diving hard into reels guides when I was first like looking at stuff and like doing the reels casts, but there was a bunch of
other stuff that was I was also listening to Ruby Rogues at the time and like a bunch of other podcasts that just like try and stay up to date, right, And how much does that.
Influence your learning ability?
Right, and like just being able to adapt to the material that you're learning. It's like almost like that, you know, reflective learning that like helps like harden and make things stick a little better.
And so it's like I always look at the survey.
And like wonder, like, you know, how do you are we capturing everything?
You're right? And I think it's always like how do you try to contextualize this in a way that's these are not like conclusive, you know, like we didn't ask people like prove it, you know, prove that this is how you learn most effectively. It's like it's like in the moment type of like responses that we're getting, So we how do we read the tea leaves a little bit, I suppose, but it's not.
It's almost like what they remember most that they think worked.
Best and recent. Yeah, right, it's still important.
I'm always fascinated about the section though, Yeah, because it does.
Change a year after year two quite a bit.
Yeah, a couple of other things in the learning.
I was gonna say that one of the one of the things I was and I haven't got I didn't get a chance to go like pivot the data to too much on this particular one, but the because you know, we're able to look at like how long people have been working.
With rails and then try to look at the data for.
That, and like if I had thought ahead more, I could maybe got some more interesting details for that. But the I was thinking one of the one of the things is that we know in the community is just that you know, this was also conducted you know, late spring, early summer ish last year, summer last year, so twenty twenty four, and you know, there was a lot of layoffs in the year prior. There's not a lot of junior developers getting hired in the community. Coding schools kind
of a lot of them closed. We used to I used to know that one of our strategies in the past to ask questions to people was to hit the some of the coding schools. They that would get shared around some of them, you know, some of those developed some of the developer they would share with their their you know, their their recent graduates or previous graduates. They would share it, you know, like here filut the surveys.
So so I think there's like data. I think we got a good capture of people that are actually working with rails right now and not too so that I feel like that's interesting, but we didn't really they also have maybe as many junior people participating or maybe because there's actually just last junior developers, uh coming into the into the market in the last year or two prior to the when we conducted this particular survey this time.
But so, I don't know, it's kind of it's it's always a little bit interesting to see how that data fluctuates a little bit, but also by how little it changes sometimes too, there's a lot of the data that's like we're looking, I'm like, how did Linux usage didn't move like like more than like a percent or two And I'm like what how despite you know, like DH is talking about it all the time or something. So it's just like, I'm like, how does this not move a lot more?
Omacoub Yeah, so Valentino, was there a section that step to you?
Yeah, I'm always fascinated to see, uh, kind of like I usued, you know, where the front end stuff shifts, because that's definitely the thing that changes the most, I would say over time.
Mm hmm.
So it's it is interest seeing to see stimulus rank so high personally, and maybe that's just because I've been stuck in a very fixed front end for for so long. Maybe I just don't see the underpinnings there, But it is interesting to see the stimulus adoption over time just get such great support.
Yeah, it's it's awesome if anyone's looking to figure out how to do stimulus with rails, I can't recommend I used this book highly enough. So yeah, I mean, on that note, though, I did notice it like you still got React, jQuery, View and next JS and Angular JS is kind of the next five and then you get to an Alpine JS, which is a minimalist framework kind of like stimulus. So of course then I kind of laughed because I saw backbone and handlebars on here too.
These things don't go away, No, they don't. Well, a lot of I mean and something I gave a talk at Rails World about dealing with like techno debt and rails applications a lot of things, and like a lot of projects have multiple job as script libraries in them because there's a tendency to, hey, we want to work on this new set of features. This might feel like a perfect opportunity to experiment with that new framework we've been itching to play with, So let's use it over here.
And so they'll add it and they'll start working on the new functionality, new features because it's easy to sneak it into that with the product and like, okay, we're going to do this over here, because it's a lot
harder to sell them on retrofitting some existing stuff. And so they do that and they kind of like the first project or two that they do is kind of like they're trying to learn on the job type of thing, and they're like, well, we learned some stuff, and like the next time, well we'll come back and refactor it.
And maybe they do or you don't.
And then a year or two later they're still working on this stuff, and then they introduce another one, and then there's another one, you know, then they like, well, we'll keep the admin area like this in this area, and then we have this other new section.
We'll use this thing.
And so then you've got like three or four different frameworks in your your your your rails application ecosystem, and you're like, well, which one is the better one. It's like, is it the newer one or is the one that
people complain about the least. And so one of the things that I've been advocating for teams to consider is, I dare you too, If you really want to use that new thing, do it on your existing stable features first, because you should already have really good healthy test coverage there. And if it doesn't work and you're not figuring it out, you can just get reverted and things are still working. But try to force yourself to implement it on existing stuff.
If that's too hard, I guarantee it's not going to get easier two years from now to do that make that change.
You're just going to stick with it, and you're going to have this.
Problem where you're not able to upgrade different things or you got all the job ascript chaos going on on your front end framework. So easier said than done. But I that's that's that's the thing that I'm trying to pitch teams to try to consider doing is like, take a hard look at the do the hard thing.
If you're not only to do.
It, stick with the framework that you're already using, because that's you're going to be stuck with it anyway.
So I'm always quite reluctant to try and rewrite features that already exist using something newer. So, uh, well, I completely agree with your approach. You're trying to introduce something new to some the feature that already exists. But where what's the judgment called the how do you decide that this is a new thing that we want to try and we're going to rewrite something that already works against Well,
that feature already works. I don't see why we should spend time rewriting it using something new.
I think the typical developer answer It depends. I think the the challenge there is, especially with soft some projects where you know that they're your team's already starting to divest themselves, and so it's interesting. I'm a big, a big advocate for not rewriting, and so like, well, I guess I'm advocating for like micro rewrites you know, in certain areas. And so it's just why do we treat like a front end framework differently than we would with like say a Ruby gem that's no longer going to
be supported, we need to migrate that. And so if the lift is so high, then I feel like we're already admitting that the front end is just going to be too much of a mess. That like we're when we make a decision, we're making a really long term decision with this, and how how can we approach that
a little bit more? Like are there ways for us to refactor parts of it, you know, like or rebuild parts of it and figure out how to glue things together like I've I've you know, work with a number of teams that in the consulting capacity where they've done like these migrations where they're moving from Angular to react or something, you know, because Angular one to Angular two was necessarily like a good upgrade path for a lot of people, and so that could happen with any of
the frameworks that you know, we talk about. There's always a chance of that happening. But for these existing stable features.
It's just more of like, if your team's trying to experiment and learn, just learn on something you already know how it's supposed to work from like a user perspective, and like can you experiment with that and test out if this idea is going to work well before you start building on some new ideas and learning on the job with that new framework, because a lot of these new frameworks don't necessarily have a lot of good documutation initially, or they have some documentation, but there's not a lot
of real world experience yet. So you're learning, you're sharing as you go. But that's but the story of the front end has been we're all learning on the job and it doesn't get it's been difficult to go back and clean things up. So I'm just trying to like a maybe advocate for like maybe there's a different can we experiment with some different approaches, because that has been
the go to approach. You don't break the existing stuff because it works great, but if it's but that's a thing, if it's going to break, how do you make it less breakable?
And so.
I don't this this is the heart, This is the hard part. Of our job, I supposed to try to figure this stuff out.
So, yeah, it reminds me a little bit of a scientific experiment, right, So you have these studies that are done right, and so they have the control and then they've got kind of their experimental set. And typically the best practice is is you only change the thing that
you want to see what difference it makes. Right, And so if you're doing a new problem and inventing a new solution and using a new tool for it as opposed to doing a well understood problem that's already been solved with the tool you already have, yeah, then you have a real good comparison to see where where the trade off is.
You might find that, you know, if you're just rebuild like a small part of your application or front end with a different jobs, you might be like all those assumptions we made of this was going to be way better, Actually, like it's got some weird things that we didn't quite realize, And is that trade off going to be okay for us in the future or because then because I think the question is going to be you start, you're using that new thing on the new functionality, are you ever
going to go back and rewrite that stuff or are you saying that those existing stable things are just never going to change. So that's why you laugh about like backbone, Like, there's plenty of projects out there that are running just
fine with backbone. We work on projects like that, and I can tell you we tried to do a project for one of our large clients that was the client was like, yeah, we want to move to react from the backbone, and we were working through this big rewrite on the front end and eventually we agree, like, you know, this doesn't feel like it's we're this doesn't feel like that. I don't want to value to your business necessarily, but
this is fine. But yeah, we're probably you know, they're like they decided they're going to end up life that particular project anyways, and then a year choose so we you know, we hit the.
Brakes on that particular project. But those are.
If where is the future of these projects going to be? And like how where do you want to kind of sit with that? And again it's a difficult part of our job, I suppose, But.
Yep, all right, I'm going to hit one of these areas that I was interested in. I'm going to talk a little bit about deployment and DevOps. I would have picked things like Ruby and Rails versions, but it seems like the majority of people are close to, if not using the latest thing, and so I was just like, oh, okay, good yeah. So yeah, So a couple of things. One is what deployment tool do you use? And the other
one was how often do you deploy? And I've always wondered because I haven't really looked at surveys like this that often, you know, are people really doing kind of the continuous deployment and then they're deploying off or are are you know, people mostly on a we're going to release after our sprint or we're going to release after our you know, after our big set of whatever, right, which is always painful whenever I've done that places I've worked.
But it looks like the majority I shouldn't say majority, but a large number of people are deploying every day or every week. I mean it's thirty seven percent for every day multiply multiple times a day, and thirty six percent for multiple times a week, which to me says that they're doing it, you know, possibly several days during the week. And so yeah, I mean that's like what seventy three percent, So that I thought that was very very fascinating.
Yeah, it kind of surprises me when we'll we'll have client engagements will come in to do some consulting for a short period of time, and those those are one of their usual questions we ask. It's like, tell us about your workflow for pushing stuff out. And then there's the companies we talk to. You are like, oh, yeah, we our team deploys.
Hundreds of times a day.
You're like, what, okay, so there's that too, the extreme of like oh yeah, like every three weeks we push out a thing. You know. I'm just like, okay, that feels like unless there's some like seven one issue type thing we need to push out, like a quick bug fix or something there's like a huge issue going on. But otherwise they're like, we don't. And I think it's
always contextual also, like you know, way to pivot. That would be like if there's a lot of restrictions in their particular industries, like maybe it's healthcare for example, or with companies and healthcare, some companies like they have very very rigorous process around that because they have to be able to have an audit trail that they can report to the governments or something. So it's a lot of
weird things that can kind of change that. So then I'm always curious about how they then have to deal with as a development workflow Q things up for a bigger bulker release versus having a lot of like these micro small things they can get shipped out. I think it depends on you know, the context, context of that particular business and industry or and a lot of people just being really you know, concerned about breaking things, like if they have a really brittle environment, they need to
really rigorous QA process before they push things out or not. So, but yeah, it's it's it's a lot, it's it's it's encouraging because I remember, I think if you go back several years that I think that the data for that would be like much lower. It would be like maybe you know, weekly would be like a pretty common thing or something.
But yeah, the other one I thought was interesting was this was the first one where Camal was listed as an option for deployment tools, and then there was one continuous deploy R. I don't know if I've even seen that or was that just a no, it's continuous deployment. It must be cut off.
Oh yeah, it's truncated and graphic chart. Yeah, end issue.
Yeah, you've got get and Capistrano. And I don't know what people mean by get. Is that like a get pushed kind of like Heroku or yeah.
I think yeah, it means which is these are some of the I feel like there's always a really awkward question because we've kept it in because people will if we just limited the set of things, like people will type in other.
They'll they'll write things in, so they'll we.
Just I think a lot of people don't know the difference between pushing too so there, but I think a lot of that comes down to, like, yeah, like Heroku is just like get pushed and then pushes to Heroku without explicitly just saying they're deploying to Heroku.
Yeah, so yeah. It said two point four percent of people reported using Kamal, which I love Kamal. I'm curious to see next time you do this when you ask about what proxy and web servers people are using, to see if Kamal proxy comes in on the list. Because traffic was the default Kamal, one and two hundred and three people said they were using that and so yeah, I'm curious to see if that switches up.
I would imagine, but you should see.
Yeah, and Thruster was another piece of that puzzle too, that's on there.
Yeah.
I'm curious too, like how many people like use chat ops still, Like is that still the go to deployment for larger organizations.
I'm curious, like do you.
Do like a lot of like you know, cross referencing post survey, like to see if like some things are related like interdependency, like you know, the their team size.
Is related to how they deploy or x y Z.
That'd be interesting.
Yeah, we definitely could.
It's just how much we've historically would share all the results with everybody and we just need to put together especially for that, and we just kind of shipped up before we had a chance to do it this year, so people can kind of play around with the data there because there's a little bit of data scrubbing we have to do for our privacy stuff there. But the
definitely something we can definitely expose for for folks. But what we found is what we've done in the past, like five people would download this and then so we're like how much how much time am I putting into something for those five people, but there is there is some there's some ways to do that as well.
You got to hook it up to an AI chat to make it easy. Related.
Yeah, and I hope that I hope that it's accurate.
Yeah.
Deploy GPT.
Yeah, if you've deployed applications using other languages or frameworks, would you say that it has been easier or harder to deploy reels applications? And sixteen percent said it was harder, but forty five percent set was easier and thirty nine percent said it's about the same, which I found interesting because I've done a little bit of PHP eight years ago, and when I could, I found it quite easy to deploy.
I can't remember exactly what I did was years ago, but it was like I didn't really know the next admin. I still probably not that good with the next admin anyway. And when I came to try and deploy a rails app for the first time, which is something about five years ago, I started using the word to live, I cave and had to use cloud sixty six and even now, like I would say that like a render dot comfort for hosting, but if I had to do like a
bare bones vps. Any Ruby, not just Raels has to deploy any Ruby web app, but it wouldn't be as easy as I as I like. So I just found that response interesting because I don't know, I mean, do you think do you think people responded easier because of things like render dot com and Heroku?
I think yeah, I mean I think that's very much the probably very much the case for a lot of people. And we definitely could look at pivoting the data data there to see if you can get some more detail on where people are hosting those applications. But it's interesting, you know, that experience you had coming from Php to Rails, Like I shared that experience early on because but that was also why part of what we did from a
company was offer hosting services to make that easier. Because it was so much easier to host a PHP application because you literally just uploaded some PHP files and maybe you needed to restart the server maybe usually.
Not back then wasn't such a big deal.
But rails, you know, you were like, well you got to run like a little Rail server, and so that that's running behind like your web server, and YadA, YadA, YadA. And then but things like Capistrano did smooth that out at one point, and Heroku made it a lot more accessible to easily quickly deploy so you didn't have to learn how to manage your own Linux server out there on some you know, rack space or wherever you're hosting your your vps and stuff like that. So I hear
you on that, is it harder or easier? I think it's To me, it feels like a lot of I think it's because that like a lot of people are like it's like thirty nine percent that it's about the same, you know, it's a little less than half and so,
but harder. I think it depends on how complicated a hosting environment are, because the other things I think it related to deploying is also like being able to debug things, and I always feel like I feel like one of the things that I really appreciate about Ruby on Rails early on was how easy it was to but debug things in production versus with working in like say PHP, because we had things like you could essensation into the server and then run Rails console and do stuff and
you're like, oh, this is amazing, and like didn't feel like we had that kind of functionality at the time. There's tools like that now, but that stuff was just kind of like a for my professional development growth. That was like a huge like aha, I'm like, look what we can do and like. But you also had to run, you know, all these different separate processes and you're spinning up delayed job things or whatever, men cash and all this stuff, and you'd have to run all these little
services in parallel on a server. So there's a lot more things related to your rails apps that you have to run as well.
It wasn't just like PHBD, like you.
Run the thing and then you had a database or something you connected to and then that was the bulk of.
What you needed to worry about.
So yeah, I think some of the tools have gotten better, like you said, but with Kamal, I mean you just you set up the vps, make sure you can have to state into it, and you know, so do run things as route and then you just tell it to set it up and then you tell it to deplay it. So yeah, I mean, depending it Yeah, a lot of it depends on how your system set up. But what I found is the tools just keep getting better and better and better.
Yeah, Comal. The only thing is it's it's Docker, and like, yeah, it's I just find it too heavy handed for the kind of stuff I do, not not for my clients work. My client work obviously is high enough scale to warrant that, but stuff I do on my own, I just find like Docker to be a bit too heavy for that. So I'd quite like just a simple solution that isn't docerbase,
and I'm playing around with some stuff. One thing that I'll be quite interested in this year over the probably this year and next year is if the adoption of Falcon goes up at all, because that's kind of designed to be like all in one server, Like you don't need to have engine X, a caddy or something in front of it. It's it's meant to be like, uh, right in front of your application, and it's meant to be like it's meant to work as a sul termination
and just work as a web server. So it should hopefully reduce the number of moving parts you need for redeployment. It would be good to see that kind of beIN a little bit more traction, I think.
Yeah, Robbie, was there a section that stood out to you that we haven't talked about.
Yeah, some of the things that I've always found interesting. The track is because it's just having been a part of the rail's ecosystem for such a long time and is a lot of the third party services and tools that we're using. So, you know, this was the first time this last year was the first time New Relic wasn't number one for performance monitoring and the rails ecosystem since we started asking that question. I think back in I think Data Dog took over the number one spot.
Otherwise New Relic had been, you know, the and I think that I don't want to I mean, I know a bunch of people that work on New Relic, but they've that company is going to have been bought and sold a couple of times at this point now. But the so it's been interesting to see that kind of evolve into seeing how like Century and ap Signal have kind of like jumped up a little bit more in
the community there. And I always it's to me, it's always kind of fun to watch like the big companies and the small companies trying to like I don't feel like that space has ever like been terribly stable for a lot of companies, necessarily outside of like the people that are at the top there, and so like we get aer tracking things and as well, so like I think on the aeroor tracking, you know, centuries top been the top of the last three times we've run the survey.
But it's been interesting. For whatever reason, I've always been fascinating with those particular those topics to see what people are using, and because I feel like it's really easy for teams to quite often switch and experiment the different
thing we come into consulting engagements. Well, like we just just actually just recently, we're working with a company doing a code at it and giving this doing some consulting with them, and we were logging into the new relic where they've been tracking their errors for a really long time and we're looking all this stuff and they're like, yeah, we don't really log.
In that offen and go look at the error stuff that often we.
Just occasionally I'm like, well, maybe a really easy thing to do is just to switch to a different platform so you have some new data, new fresh data set rather.
Than just ignoring the old thing, and like you can use my U.
So they got set up with like app signal like in an afternoon and you know, maybe made a confute a few co changes to make that work, and then it just kind of revitalized the team a little bit to start paying attention to that stuff a little bit
more thoroughly. And so that's always kind of a nice thing to be able to know that there's other tools that you can kind of play with and maybe get a different perspective or look at your data and you're the activating your applications from a different perspective, and so maybe switch over to honey Badger for six months and try that for a bit and see how that maybe
rethinks your how your team approaches this stuff. Those are like usually pretty easy things that teams can do to just get some new energy around something rather than being like, let's log into the thing. We don't really pay tension or I don't really like.
The UI or all the upsales that they're.
Doing and not trying to pick on new relic or data Dog or whatever, or like people like yeah, data Dog, they as soon as we sign up for account with them,
all over. Developers start getting emails and phone calls all the time from their sales people trying to upsell, and you're just like, yeah, that's going to happen with this bigger company, so other things that I know interesting around just seeing things like what debugging tools people are using, because there's you know, there's new things popping up, and like Ruby Ruby de bug is what sixteen percent now and you know the prize at thirty one percent, and
so I think if you're just people, like a lot of people just keep using the same thing that they're already used to using for a long time. So I think it's sometimes it's just helpful to be aware of
these things counterpoint. And you know, you mentioned like the Ruby versions or we would ask you know, which which version or Ruby you're using, not not just like the number version, but if I're using like Matt's is Ruby versus j Ruby things like that, and let me see if I try to remember what the question is, but I got I'm not trying to point out unnecessarily, but we ended up because the data from from the survey the previous years that jay Ruby was so low in
number of counts that I'm like, I don't feel like it's important to keep is that even an option for people to check anymore? Because there's another box and let's just let people type it in and then that didn't make someone all that happy that I removed it. I'm like, well,
I'm not seeing people can't do that. It's just like there's this insignificant number point that I'm like, and they're well, this is like a So some people see these these are the types of surveys as an opportunity to highlight that there are these other tools when they're picking the survey that they could be exposed to. So I'm like, I can't list every single jam, every single.
Third party service.
It's just like we got to kind of do our best to try to encounter like what do we know, because there's a lot of things about the community and the tooling that we don't even we're not even aware of. So this is when we I'm usually learning about anythings, like oh, what's this falcon thing? You know I've heard maybe mentioned, but like a bunch of people are using it. I'm like, I didn't even know anything about it. So that's always kind of like a fascinating part of the
surveys too. It's it's it's it's it's it's easy. It's not easy to get a lot of people to felt the survey, but it's an easy way for me to learn a lot about what people are up to in the community, so kind of selfishly, yeah, I always wish there's like a Ruby toolbox for like services, you know, Oh everybody's using this or what is this? You know?
Uh, yeah, I don't know. I feel like that is kind of missing.
It's a fair point. If anyone listening wants to create a some sort of project to do that, I think that would be good. But maintaining that keeping an updated this is another thing.
So yeah. One thing that I picked up from the survey that I didn't know existed was in the version updates. It said, is your team using a dual boot strategy for upgrades? And I was like, wait, you could do that? So I had to go google it.
Did you learn much about about that? That said, there's a couple of really good tools for that that'll be used.
I found a gem that does it, and I didn't get much further than that.
But I'm surprised that the boogoot gem.
That was from shopify someone that I found.
I'm surprised that after all the conference talks about it, that hasn't gotten more adoption.
It's not that hard.
Yeah, I'm working a project now. That we have some performance issues, that there are tools in rail seven to two that are not in Rail seven oh that we want to use, like common table expressions and the way we want to do some of the things with those. So yeah, I was like, huh, well, maybe we can use this over there and see how far we get.
Publish this back in right right before world So I'm trying to remember the things that we're kind of like capturing my mind at the time. But the the other part was just like the just reinforcing the monoliths, I suppose, and like that the number of people that are focusing building a lot of micro service has been trending down for the past I think like last three surveys, so say six.
Years or so.
So that's been something that's been interesting to see that there are and I know that there are a number of teams just from doing consulting and talking with different companies that are consolidating a lot more stuff and trying to do more monolith Their app or at least have to be a bit more hybrid than like because they're teams shrunk and it's a common pattern that like we make a lot of decisions as teams assuming that especially for hired during a growth period that we just assume
that the team's going to continue growing. And then so how do we architect our system to support maybe a one day larger team. And we don't often make a lot of technical decisions with the assumption that we're going to be a smaller.
Team in the future. And maybe that's actually an ideal state for that team is to be smaller.
So how do you weigh kind of weigh those two things up, Like, we don't we may not need the team we have today in two years to support this thing, and that's maybe ideal. Whether the leadership is talking about that out a lot or not, that's maybe another issue, but that is like a thing. And so like, I
know a lot of like really really small teams. I'm talking like two or three people that are working on software projects that I've got like twenty five micro services and you're just like, I'm like, this doesn't seem fun. How many rails upgrades are you doing? And like, okay, well we did this when we were ten people. I'm like all right, and then and like and most those
people aren't even here anymore. So you're just like, okay, well this is a fun thing to kind of re reconfigure and rethink about how you reframe this stuff, because like we had to make a change, and we now we got to make a change in three different repositories. Figure out the deployment process, scheduling because like these are not this this, this doesn't feel super efficient. And it's some very similar to the front end framework type of
issue as well. But micro services and the monolith thing, I think it's so monolists are on the rise in terms of people trying to keep it keep it in like one repo as much as possible unless you really really need to start putting some stuff out.
I'm curious how much of that is thanks to pop packwork, because that seems to be a common pattern. Is like making micro services in your monolith with packwork, which seems to like solve kind of both problems that people face. Uh, and the people that want to push for micro services feel at ease because it kind of feels like a micro service in a way. I don't know what you're what your thoughts are on that.
I know that I Aleen gave a talk at Reil's Word about that, and it was kind of a little bit critical of doing a lot of that because there's very because often the boundaries are not so clearly defined and people are like stuff is overreaching all the time. Anyways, I don't know that she felt like she had like a good way of solving that necessarily, but like I think her perspective is like we might.
Have over we're still over.
Separating in a way trying to optimize, and it's causing other sorts of issues with like ownership within projects and feeling like how did how did just teams.
Work together own projects? Is I think another part of it.
So there's the human part of that, and then there's the technical approaches to solving some of that stuff and like trying to weigh that up when the teams are maybe not always going to match the technical separation of those concerns and so I know, it's it's it's it's it's tricky. So but yeah, packwork is definitely an option there for kind of approaching them.
Yep.
Yeah, I like to try ways from uh just like the open ended comments was, uh, you know, move away from over engineering.
Things optimize for a smaller team, And I think even if it's the same size team, like if you can make this your software project easier for when half of your team is on vacation to maintain, Like, wouldn't that be a good thing? Wouldn't that feel better? I just think there's probably a lot of things that we could be asked for, so like like like especially with like deployments, is you brought that up as an interesting thing, like there was a time when, like we've I think there's
a lot of benefits. And one of the interesting things about why Camal's resonating with some teams or some small teams in particular, is that it feels like it's giving back some control to the developers a little bit because I think within this era where there's a lot of emphasis on you know, DevOps type roles and people, there's some specialization that came about, you know again, and so we've this was a very similar pre you know, go back to.
The early aughts.
We had a lot of DBAs you know, in our in our teams, someone that would manage the database and be the guardian and the gatekeeper for adding new columns your table, adding new views or soot procedures, and the may'd be the ones who managed that. And we were able to kind of take some of that and like, no, we can do this ourselves. We can we can manage this.
And then I think over the last decade or more, we the infrastructure has got more complicated as we've moved to the cloud, and we can do all this stuff. And so we have a lot of a lot of really large teams really need to do with a lot of scaling things. A lot of small teams have some scaling issues, but they would then adopt a lot of the same approaches that large teams are talking about because and so a lot of developers are actually so I think back to the question about is it harder or not?
Is like some people work in environments like and actually not responsible for anything but pushing to a branch and then some magic happens. But ask me to change that. I don't even know where to start. What is this terrorform stuff, this cooper net?
What is this like?
How does this stuff work? I don't have time for that. I'm going to focus on rails and I think that's okay in some teams. But it's been a challenge for a lot of developers to feel like I can make changes or I feel it feels very brittle at times because there's some magic stuff that's happening over here, and I don't.
Want to break the infrastructure.
So infrastructure became a challenge and kind of like just to kind of come back to this is just so those a lot of teams don't feel like they can make those changes. So teams are a lot bigger more because there's just people that are specializing in certain things.
And you got that.
Now you have that weak point of like what happens if that infrastructure person leaves or you need to keep them around, and maybe they're not the best person to be part of your team. And so I think there's like a little bit of things like comal kind of like pulling that back a little bit, like we don't need all that stuff for a lot of software projects. We can do that, but does every project need to be deploying every single commit.
Automatically? Like that's maybe I don't know.
Maybe maybe you could just wait till someone runs in the command once a day and that would be fine. But there's gotta be some trade offs there because you're spending a lot of money on infrastructure stuff and all of those get up actions running or whatever you're using for all that stuff. But that is costing your company money to do that stuff and it's not free, so figure out how to balance that.
Yeah, all right, Well we're kind of getting to that point in time where we go to picks. Before we do that, though, Robbie, if people want to connect with you online, or they're thinking maybe they have a project where they need help from someone like Brent planet ar Gone, or they want to listen to the maintainable podcasts, where do they find any of that stuff?
Search for it?
I mean, you know how to do this stuff.
Links.
I'm sure there will be some links in the show noteswer I'm Robbie, Robbie Russell or you can find me.
All right, good deal. Well let's uh let's do some picks. Are you sh you want to start us off picks?
Yeah, that's uh. So she got back from New Zealand, so I'm just gonna New Zealand as a country. That's gonna be one of my picks. It's just them, It's it's probably our favorite place to go on holiday. I was there for like six weeks and yeah, the place feels fictional.
Man.
I went did also, I went to hobbiton so I got got this thing from from from hobbiton, which is a I don't really do bucket list, but if I had a bucket list, I would probably be on there. Uh yeah. It was also nice to just get out of the British winter for a bit. But near New Zealand as a country is one of my picks. And then I got back and I binged a new TV
show because that's what I do. It's called A Man on the Inside starring Ted Dunce and it's Michael Shaw's new comedy known for other shows like Parks and Rack Brooklyn nine nine in the Good Place. So his new shows as like, what's only eight episodes to spend an evening and binge the whole thing. Very funny, very enjoyable. Recommend that. And I'll finish off with that technical pick,
which is the acinc container gem by Samuel Williams. I have the chance to hang out with him while I was in New Zealand, and one of the things we kind of played around with was the acink container gem, which it's kind of just a way to like orchestrate
roovy processes. So instead of like packaging everything after the darker container, you just have any acinc container manage all your different processes, and it kind of deals with restarting and blue green deployers and all that kind of stuff, and kind of playing around with it to see if I can get it to work nicely with just generic rails up with apps be mine stuff. But yeah, I think it's a very underrated gem and they I highly
recommend checking it out. So yeah, those are my three picks for today.
Awesome, Valentino, what are your picks?
I just got done taking this incredible Ruby AI engineering training and planning workshop with Max Irwin and Landing Gray.
I highly recommend it.
We got a bunch of folks at doximity to attend it and just like filled so many knowledge gaps and just learned a ton and I'm looking forward to applying just like, yeah, a massive amount of information there.
So definitely check that out.
I hope they continue doing it, because yeah, I was just incredibly well put together, and I've never used Jupiter notebooks with Ruby before, so that was very interesting and kind of fun.
Uh So uh that that on its own kind of worth it.
My My other.
Pick is I I just pre ordered this giant three D printer from elagu. It's uh it's called orange Storm Giga and you can print like furniture size things with it.
So I'm I'm pretty excited to Uh.
You meant giant.
Wow, I went giant is massive. Yeah, it's the size of a person. Uh. And it's honestly not that expensive for what it is.
Uh And so uh I recommend at least looking at it. It's pretty pretty incredible what you can do these days.
Nice your friends come over and ask you what you do in your phone booth. All right, I've got a few picks here, so I always do a boarding and pick first. And so the game I'm gonna pick this time is Machi Koro two. I have picked Machi Koro in the past. Machi Koro two is you basically played
by the same rules as Machi Koro. The difference is is that you have instead of the different kinds of buildings just being all in their stacks and you can just buy whatever's out there, you actually flip cards to expose the different types of the different buildings. And so, just to give a quick rundown on how the game works, you buy buildings, you roll the dice. If you roll at dice on a card that you have in front of you that's green or blue, then you get then you
get money. If anyone else has a red card with that number on it, then you have to pay them money. And the green cards on other people's turns you also get paid for. So that I mean that that's more or less it you're trying. The way you win is you build three No, you build four landmarks in Machi Koro.
Everybody has the same landmarks in Mahi Koro two. One of the piles that you're flipping cards out of to expose which landmark you can build or is the landmarks, and then the others are the different building types based on costs or based on the number year role. So one through six and then seven through twelve. I mean that's it. You just go until somebody's built three landmarks in this game and you're done. And it takes forty five minutes maybe to play a full game. It's relatively simple.
I think it's rated ten plus, and I think the kids younger than that, not a ton younger, but younger than that could probably play it. My nine year old could probably play it just fine. It let's see has a board game weight on board game Geek of one point four eight, So you know, Casual Gamer a little less complicated than some of the other games out there. And yeah, I just we had a good time playing it, so got it for Christmas. So I'm gonna pick that.
And then I've been I started the Stormlight Archive series by Brandon Sanderson again and so I'm enjoying those, so I'll pick those, and I'm trying to grab a link for those. I think that's basically all I've got for picks this time around. I started playing with open Router. I'll guess I'll pick them too. There's a gem for that. It's written by Obi Fernandez, and it lets you use the different AI l ll ms and things like that
for some of the stuff you're doing. It's it's what he recommends you use in his book about the AI development. So anyway, check out open Router and the open Router. Jim and Robbie, do you have some stuff you want to shout out about?
Yeah, let's see a couple of things that come to come to mind. Is a quick shout out to Joe Mazzati for releasing hot Wire Native this last week. It's out on beta now, So if that's something you're interested in him and I are going to grab coffee next week. So we live in the same town, so we can see each other every once in a while. That's always fun to catch up with him. And then also i've been real quick. We're gonna have Joe on in a few weeks to talk about Yeah, in a few weeks
to talk about his book and the stuff he did wonderful. Also, I've been a one of the things you mentioned talking about Oma Zeshell. Wild thing about being part of that CLI environment is that I get approached by a lot of people that are building new terminal emulators all the time, like, so usually get to be get early access to tools
and get to be early testers for things. So I've been using a thing called Ghosty for I don't know, maybe nine months off and on, and so that got released a couple of weeks ago, and that's why I was released by Mitchell Hashimoto. And it's pretty slick, and I think there's gonna be a lot of fun innovation on the our criminal emulators in the next few years, so that'll be kind of exciting non tech related stuff
I'm trying to think of. It's like coming out of the holiday season, but I recently watched the Penguin series on HBO Max. I am not a comic, but personally I don't go on my way. I watched like the Batman movies every once and a while and stuff like that, but I wasn't sure if I'd liked this type of thing.
I loved it.
It was such a good I really really enjoyed that that series. And yeah, I would just say that that was good. And then also one of my favorite bands, Magwife from Scotland has a couple of new singles out and a new album coming out and they're a huge influence on my band and my my own music. Its influence, so check out the I had another new song called I think it was called Fanzine Made of Flesh or something as the name of the new song that came
out this last week. That that's pretty good. So I'm pretty pretty excited to get to see them and again when they come on tour soon.
So there's those are my picks, all right?
Good deal? Well, thanks for coming. This was fascinating conversation and it's always good to catch up.
Yeah. Likewise, nice to meet too, Valentino. I uish and thanks for having me and talk to you again some about the point in the future. I hope