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