Rails Developers Survey: Continuous Deployment Trends and Emerging Tools - RUBY 670 - Ruby Rogues

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey folks, welcome back to another episode of the Ruby
Rogues podcast, the Sweet Conod Panel. We have a Yushnawatia Hello, Hello,
also a Valentino stole in.

Speaker 2 (00:16):
Now.

Speaker 1 (00:17):
I'm Charles Maxwood from top End Devs and this week
we have a special guest. We have Robbie Russell from
Planet Are Gone. Robbie, do you want to I don't know.
I'm like, where do we even start? You know, O
my zshell or what's.

Speaker 3 (00:31):
A amazy show?

Speaker 2 (00:33):
Now? Yeah? Hi nice, thanks for having me on today.
Good morning, Good afternoon everybody. So, yeah, I run a
company called Planet Argon. We're a soccer consultancy. We've been
around for twenty almost twenty three years now, part of
the Rail's ecosystem for just over twenty years now, and
we help companies with existing rails applications make them better

(00:55):
and more maintainable.

Speaker 3 (00:56):
We do a lot of consulting work in that space.

Speaker 2 (00:59):
And I also so I'm known for having created O
my zshell Once upon a Time, which is an open
source configuration framework for z shell if that's something you
like to use on the command line, and an open
source contributor for about twenty five years. I'm also the
host of the Maintainable Software podcasts, where I interview people
about best practices when it comes to taking care of

(01:20):
older legacy applications across a lot of different frameworks and
tech stacks. That's not a rail specific but there's a
lot of Ruby and rails related contact because that's my
orbit that I exist in, and I also play guitar
in an instrumental rock band called the Mighty Misula.

Speaker 1 (01:37):
Cool. I didn't know about the rock band. I admired
you from Afar for a long time for all the
other stuff. So yeah, it's exciting to have you on.
We brought you on to talk about I got an
email from you. I think I'm on an e mailing
list somewhere, and it basically said the Stimulus JS replaced

(01:58):
Here we go. Stimulus has dethroned reacts as the most
popular JS library for rails apps. And so then I
went and looked at the survey and that that was
kind of interesting. I want to ask you about all
of the other things though, so sure, uh yeah, let's
go ahead. And I just want to get a little
bit of background. I mean, I use on my z

(02:19):
shell and it's oh my helpful and so I'm curious
what the story is behind that. And then I'd also
like to talk a little bit about Planet Argone before
we get into survey.

Speaker 3 (02:30):
Yeah, yeah, that sounds great.

Speaker 2 (02:31):
So oh my DHL. I first, really, we celebrated fifteen
years that I since I released it back and I
think it was August now, it was fifteen years ago,
so fifteen and a couple extra months now.

Speaker 3 (02:43):
I have been using ZHL for a couple of years.

Speaker 2 (02:45):
A lot of peers in the Ruby ecosystem at the time,
we would all share a little configuration ideas for how
to use VHL and optimize it and get was kind
of a new thing at the time, so doing things
like having your giit branch in your prompt was kind
of a really new cool idea and I think it
helped us. I think it was this a good timing
overlap with trying to wrap her head around like local

(03:07):
branches at the time. So but basically I had compiled
this crazy z shehell configuration file that half of it
I kind of understood half of it. I probably didn't
because I was just copy and pasting and trading things
with my friends over IRC channels or old websites like pasty,
which was kind of like a gist before get up existed.
And I would be parent pargnering with one of my

(03:29):
coworkers at my company on a thing, and we'd be
on their computer and I would get frustrated because all
of my muscle memory wouldn't I remember how to do
how to fully write out of the commands because a
lot of shortcuts and aliases and little optimizations that I
had added to my own configuration file. So I was
I found myself just feeling frustrated with myself, and so
I'd be like, hey, why don't you use zshell and

(03:51):
just copy my configuration file and then and then I'll
show you how you can be quicker at the command line,
as I feel like a lot more efficient now. And
so I would kind of encourage my team to do that,
and a few people would take take me up on that,
but several people didn't like one person, particularly named Carlos,
on my team. He was very resistant to because he
didn't he wanted to understand what the config file did.

(04:13):
And I was He's like, well, walk me through it,
and I'm like, I honestly can't because I don't really
understand a lot of this gibberish z Sholl sent text
does and so we kind of, you know, we butted
heads a little bit, and he wouldn't take me up
on the idea. So I decided one weekend, I'm like,
you know what I'm gonna I'm going to try to
document my config file. I'm gonna go through and just
add some comments. I'm going to like look up the

(04:34):
documentation in the z shell syntax and I'm going to
try to understand this. And then as I started doing that,
I started like refactoring it basically and moving in and
I'm like, well, this is like a really big file.
What if I made I should probably use some version controls,
So I'll put this in and get repository. And I
started making like separating out this big config file into
several smaller, messy config files. And then I slapped a

(04:55):
name on it, and I called it on my seashell
because it was a playoff of another project that I
had worked on a.

Speaker 3 (04:59):
Couple of months before, or with a different coworker.

Speaker 2 (05:01):
We didn't really put a lot of thought into that either,
but I created like a read me with an install guide,
which was basically like a get clone of this repository
that I created, and then and then you could use
my knfig file, and so I felt like I just elevated.
But that was like maybe a handful a few hours
worth the work of cleaning up that file and turning
it into this new repository. Threw it up on GitHub,

(05:22):
and then I dropped that link I don't remember if
for using campfire or some other chat tool back in
the back in two thousand and nine, dropped it in
our team's chat. Everybody installed it on Monday victory I won.
Everybody now had my canfiic file, so I would go
to the computer and I would all the same things.
So that was my goal, was just to have everybody

(05:44):
in my office kind of have the same ISSU configure,
so that I could show them how to feel like
a superhero and the command line, and I wouldn't have
to remember how to like do everything like write out
all tho syntax for a lot of the obscure commands
that we were running. But then, so the thing that
a lot of people know about owens the shells that
it comes with a lot of themes and tons of

(06:05):
plug ins, and like none of that was remotely on
my dea my was it even something I had considered?
That next day, one of my co workers, Gary said,
how do I change the colors? I was like, why
would you want to do that? My color choices are perfect?
And I was like, well, here you can go in
this file. I moved like I think I had like
colors or prompt file configuration files. I'm like, you can

(06:27):
change the colors in here, and here's like the syntax
for that. So we started doing that. He started making changes,
and then other team members wanted to add contribute their
own little shortcuts and little functions and aliases as well,
and so we were kind of working together on this,
and Gary couldn't do a get pull and get pushed
cleanly because he had changed the file, you know, and

(06:48):
get conflict, and so we're like, so we're like kind
of like, well, so we had like stash it and
then pull the changes and then reapply them. And I'm like, well,
this doesn't feel very sustainable because then another co worker
is like, I want to change the COLO and so
I was like, well, what can.

Speaker 3 (07:03):
We do here?

Speaker 2 (07:03):
And I was like, oh, I know, I'll just move
my prompt file into its own thing and call it
Robbie Russell.

Speaker 3 (07:09):
We'll call it a theme. These are themes.

Speaker 2 (07:12):
Gary has his, I have mine, Carlos can have his,
Allison can have hers. And so it created the concept
of themes, which became like a configuration option. And so
then I met I mentioned it on my blog and
Robbie on rails back in the day, and so it's
mostly within the Ruby ecosystem. And then about a month
later we started getting contributions. But about and a lot

(07:32):
of themes started popping in by other people as well,
so that.

Speaker 3 (07:35):
Was kind of like a fun thing.

Speaker 2 (07:36):
I suppose, like, hey, we have this real repository.

Speaker 3 (07:38):
We can inspire each other.

Speaker 2 (07:39):
And about a month later someone reached out and said, hey,
this is really cool, but I'm a Python developer. I
don't need all this Ruby stuff loaded up when I
when I run this, Like I want to use the
prompt stuff with all the get stuff, but I don't
need all the Rails and Ruby stuff that you have loaded.

Speaker 3 (07:52):
So I was like, oh, that's interesting.

Speaker 2 (07:55):
I don't want all that pie stuff Python stuffloaded when
I use it, so maybe we'll all these plugins. And
so I moved all the Rails stuff and Ruby's stuff
into its own thing, and we had Python stuff come in,
and then that just opened the floodgates for other people
be like, oh, I got this thing from my framework,
or I had this other tool that I'm only using.

Speaker 1 (08:12):
And so.

Speaker 2 (08:13):
This stuff kind of organically evolved as the community started
using it and pitching ideas, and I was like, well,
here's a way to kind of organize that. We'll just
throw these in different directories with different kind of enable
these things, and that just kind of snowballed into this
thing that's kind of evolved over the last fifteen plus
years where we've had several remember the number of I

(08:34):
think we've had, Remember how many couple we've had more
than a couple of thousand contributors directly to the core
project contribute code, and it's one of the most like
starred projects on GitHub and it's kind of wild. But
I don't make any money with it. I sell stickers
and T shirts. That's fun. But it's always been this

(08:55):
kind of like fun, little open source thing that I
can occasionally spend some time thinking about, but it doesn't
occupy a lot of my brain space. Despite how wildly
wide ranged in popular it has seemingly been.

Speaker 1 (09:09):
That's awesome. I love it. Yeah. I also want to
just talk a little bit about Planet Argon. You guys
have been around for a while. Was this before or
aftermyzshell and before?

Speaker 2 (09:20):
Yeah?

Speaker 1 (09:21):
Yeah? Story with yeah how that got started?

Speaker 2 (09:24):
So I actually started planning Argon I see back in
two thousand and two as a what I would because
I was had a day job and I was like,
I want to do we work with I worked at
a company in some software development and we were uh
that company was a dot net shop, and I was
really interested in open source, and nobody at larger companies

(09:44):
was really hiring open source technology people that often, and
so I love PHBA. It was really it. Had co
founded a Linux user group here in Portland, Oregon, and
so I was already kind of doing a lot of
fun open source stuff, and so I was like trying
to trains like, Okay, I do this net how do
I do this in PHP? And then I started like,
you know, maybe I can get some freelance work on

(10:05):
the side, And so I decided to incorporate that as
a plan Argon. Thought I would make it sound like
I'm bigger than just me, and it was like me
and then my partner at the time, she was a designer,
so we would. She would work on web design stuff
and I did a lot of back end development, so
we collaborate on stuff. So she had her company, I
had mine, and so we so I was like, I'm
gonna call my planet Argon, which was a reference to

(10:28):
a fictional book or a fictional place in a Tom
Robbins book called Still Left with Woodpecker, which is where
redheads came from. So I had nothing to do with anything.
It wasn't some clever idea of gases or you know,
the scientific chart there. It was literally just like a
it's me, I have red hair, plane ragon, goofy little thing.

(10:50):
So I did that for a couple of years, doing
like side projects. In two thousand and four, I quit
my last job to work full time on Planet Argon,
just as a you know, freelance insultant. And then and
beginning of two thousand, late two thousand and four, begin
two thousand and five, I got introduced to ruby and
Ruby on rails and started doing that.

Speaker 3 (11:07):
In two thousand and four, beginning of two thousand and four.

Speaker 2 (11:10):
I started blogging as robbyond Rails and so this was
five and a half years before Always You Sholl existed.
I was part of the Rails ecosystem and doing stuff,
so I think always sholl Will just kind of culminated
it out of that community. So yeah, it has been
around for a while. What we work on a lot now.
So back then, it was a lot of like new
startups wanting to use Rails because it was kind of

(11:31):
like this new hot thing for projects. So we learned
how to basically went from that freelancer space of me
working on by myself with my designer partner at the time,
and to all of a sudden, like some really large
projects started coming our way that would take more than
me to be able to do it. And so one
of the first services that we had was offering hosting

(11:51):
services to rubyond Rails developers because there wasn't a lot
of affordable hosting options unless you spun up your own
BPS or something. So I had been offering post rescuels
hosting for developers and like PHP five development or environments
for hosting because I had a lot of experience with
like writing servers and stuff like that. So that was
part of our services early on, was posting, even going

(12:14):
back to two thousand. I think we started doing that
in two thousand and three a site for a lot
of the projects because i've it then host those projects.
So we were one of the first companies in the
Ruby on Rails ecosystem to start offering hosting at kind
of like an affordable price point, and we give people
like shared hosting environments and made that kind of work.
And then so that allowed us to broaden our exposure

(12:37):
in the community early on. And then but a big
part of what we were trying to do is just
focus on developing sort of projects and stuff like that.
And then a couple of years into that, we started
getting approached by companies that said, hey, we had a
couple of freelancers build this app for us this last year.
They're no longer available, they got full time jobs. Some morals,
can you take over these projects? And one of the

(12:57):
great things about Ruby and rails was that it was
there's a consistency between projects. So we found ourselves being
able to like jump in quickly to existing projects and
that became our niche over the years that now we
quite essentially take over projects that are for companies that
don't necessarily need to have two or more full time
software engineers on their team in house, and so their

(13:19):
other option is maybe having like a freelancer or two,
but then maybe they do that, but the freelancers kind
of come and go, and they're like, we have to
kind of restart this process a lot. So we end
up owning a lot of projects where we're the primary
development team for like five ten years with some of
our clients, some of them over ten years. Now we're
their dev shop, but we're maybe doing like eighty.

Speaker 3 (13:37):
Hours a month on those projects.

Speaker 2 (13:39):
You know, it's kind of like a but we're maintaining
those things for the long term because they don't necessarily
they're not trying to become a company.

Speaker 3 (13:46):
It's like an application that helps fulfill part.

Speaker 2 (13:49):
Of their business, but it isn't the business.

Speaker 3 (13:51):
So like there's a lot of.

Speaker 2 (13:51):
Those types of applications that exist, so we're kind of
well tuned to come in and own those types of projects.
But then we also do a lot of consulting and
coming in with companies that have their own engineering teams
on helping them unblock themselves when it comes to like
there's been a lot of turnover in those environments and
maybe some of the original developers have you know, left,
and some of the new developers aren't sure how to
like make choices about, Hey, we're still running on rails four.

(14:17):
We would love to get to seven, eight, but how
do we get to five? And how do we kind
of navigate this and what frameworks and front end things
should we be exploring now, And so we try to
help come in and help coach teams on how to
navigate some of that stuff and cleaning up techno debt
and deal with overdue upgrades, performance improvements, stuff like that.

Speaker 3 (14:34):
So that's another part of our business as well.

Speaker 1 (14:39):
Nice okay, well more, Yeah, maintainable podcasts.

Speaker 2 (14:45):
Yeah, so maintainable podcast just recently recorded my tuneth episode
of that. It's an interview style format visions And one
of the things I set out to do was I
felt like there's always been a lot of good quality
conversations around what's going on new in the software industry.
New people always like talk about new stuff, and I

(15:06):
was like, but a lot of software developers experience is
showing up to a job where things are already there,
things are already in motion.

Speaker 3 (15:13):
And I think as.

Speaker 2 (15:15):
A industry we've done ourselves to disservice by branding ourselves
as being these like creators, makers and like, but reality,
most of us are actually mending and taking care of
existing stuff and trying to just make it a little
bit better today than it was yesterday, leave things better off,
and like, that's good work to be done. And I've

(15:38):
just seen a lot of developers over the years struggle
to kind of like change like reframe that because I
think we've but anyways, so I thought, I thought it
would be interesting to have conversations about what it's really
like to work at project on projects day in and
day out that have been around for a really long time,
and how to make incremental improvements because that stuff is

(15:59):
hard and there's a lot of people dynamics, there's technical
dynamics at play, and so I wanted to just a
catalog a lot of conversations that I thought would be
relevant today but also in ten.

Speaker 3 (16:09):
Years, twenty years from now.

Speaker 2 (16:11):
I don't feel like these are conversations that will date themselves.
So I'm trying to be very intentional about having conversations
with people about how they navigate, how they've overcome, or
sharing some of the painful stories about like yeah, we
tried to do rewrite and that blew up in our phase.

Speaker 3 (16:25):
Because I'm a big.

Speaker 2 (16:26):
Advocate for not rewriting unless it's the very very last
possible step you can possibly do. So I'm always like this,
there's got to be a better way to think about
how your approach to software projects rather than just dreaming
that one day we'll finally get to rewrite this thing
and then it's all going to be better. We will
never have all these problems that we have today.

Speaker 3 (16:43):
Which is complete bullshit.

Speaker 1 (16:45):
So right, cool. Well, I have to say I've listened
to the Maintainable podcast for a while and you always
have terrific people on that make me think about how
I do it.

Speaker 2 (16:54):
So that's great, I have It's it's also just a
good excuses get to have conversations with people that I
admire on a regular basis.

Speaker 3 (17:03):
I'm like, this is that's my favorite part of it.

Speaker 1 (17:06):
Awesome. All right, well I'll quit fan boying and uh,
well we'll we'll talk about the survey. So yeah, yeah,
so do you want to just explain I'm always curious.
I used to just be like, all right, well, let's
just get into the meat. What's in the survey, right,
And I think that's important, but I like to get
into the methodology a little bit. Right, like who who
did you reach out to, how did you market it,

(17:28):
what kind of people did you expect to take it,
and and that kind of thing, so that we can
get an idea of, Okay, this is the community it
really reflects.

Speaker 2 (17:36):
Yeah, yeah, that's a good question. So just for some
historical context, the survey, we've been running the survey as
long as always You Show has been around. So the
first time we did it was back in two thousand
and nine, so I think we've done it eight times now.
Pretty much has been every other year, except for I
think for the first couple of years we did it
like every year. But the original version of it was

(17:57):
we wanted to get a lay of the land of
because we were part of our business was doing hosting.
Was like, how how is the ecosystem changing in terms
of how people were thinking about deploying and hosting their
applications because we were providing those services and the cloud
services kind of this new thing, and we're like, is
that where everybody's moving? Should we get out of this
part of the business. We ended up using that survey

(18:18):
result that first year to decide to sell that part
of the business off, and so we're like Okay, we're
at we're not gonna be.

Speaker 3 (18:23):
Able to keep up.

Speaker 2 (18:24):
Let's just let them I'm done going to the co
location and stuff like that. So we use the survey
to make a business decision, but we decided we publish
all the results for everybody make it because we were like,
there's a lot of other interesting details in there around
like what their party services people are using, and like
we're using.

Speaker 3 (18:38):
For error monitoring or performance tracking.

Speaker 2 (18:41):
Things are just again and get a sense of like, well,
how other people are doing because people can go online
and ask those questions you know, in IRC chat conversations
back in the day or some forums or stack over
floor or whatever, and I was like, we kind of
wanted to just like let's get a broader range of people.
So we've been doing this, you know, every other year
since then. So this last year when we did it,

(19:03):
our typical approach has been one reach out to people
taken in the past, and so a lot of those
people came to us from social media, following us on
different blogs and stuff like that. Reaching out to the
mailing like the Rails, Rails Talk mailing lists and other
groups that were you know, we're around at the time,
but So for this last year, we did put a
lot of energy into working with the Rails Foundation, in

(19:25):
particular Amanda there and so uh, she had approached me
the year before when she first got hired at the
Rails Foundation to talk about the survey. She actually that
was the first time I actually spoke with her about it.
Was she reached out and said, Hey, I want to
talk about the survey and the Rails Foundation. I was like, Oh, no,
they're gonna They're gonna start doing this themselves, and I
guess we're no longer going to get to do that.
That's that's what I was preparing for, Like, I guess

(19:46):
we're kind of out of the business of doing this,
and it's a lot of work to run the surveys
and stuff as well, So it wouldn't be the worst
thing in the world. But through that conversation, I was like, Oh,
they have very different things that they're looking for than
we do. But what we did decide to that we
would go to the Rails Foundation. So they took that
to the board and be like, what sort of other
topics and questions might they the other Foundation members like,

(20:08):
you know, shopifys and doctimity and companies like that might
be interested in hearing about the ecosystem right now, and
so we we got some new questions and topics and
a lot of that came up. So we ended up
adding a lot of new questions related to education and
like how people are learning about rails or how they're
what type of content are they consuming to level up

(20:29):
as developers, and is the assumption that video stuff is
the future actually resonating with the majority of developers, So
that we can get into some of the stats there.
But in terms of the reaching out to people, it
was a lot of hitting the social media as I
emailed everybody that I could, you know, I had reached
out to in the past, and to have anyone that

(20:53):
I knew that's written books in the last few years
about Ruby or rails related themes, or people I've interviewed
that happened to be part of the ecosism them like
reached out to them, emailed them like, hey, can you
blast this to your group or your mailing list, anyone
that runs a mailing list. So we have like a
big checklist of places that we reach out to, but
we do want to make that as broad as possible,
so it's not.

Speaker 3 (21:14):
It's not just like maybe.

Speaker 2 (21:15):
One company that's like Shopify drops it in their internal
chat tool and then it's just like half the you know,
the people are just Shopify employees filling it out and
all the data looks the same.

Speaker 3 (21:24):
So so and.

Speaker 2 (21:27):
So I'm always worried that that's going to be a
thing because it wouldn't take a lot for like something
to drastically skew the data when we've got I think
we had a little over twenty seven hundred participants, which
is the most we've ever had. A lot of people
want to fill out a sixty question survey, you know
that often, so it takes a little bit to go
through that process. But but that's where we're able to
end up. So that answer your question enough, I suppose.

Speaker 1 (21:51):
Yeah, yeah, I think so. I kind of want to
pull Valentino and I use it in Did you guys
get a chance to look at the survey? And I'm
curious was there anything that stood out to you because
I don't know which section to really start with why.
I have some ideas, but I want to hear from
you guys.

Speaker 4 (22:09):
Yeah, I think I looked at at when the results
first came out because I'm fairly sure I actually did
fill it out, and I can't remember whether I did,
but I'm like ninety nine percent sure that that I
did fill it out. A couple of things that cut
my One was obviously the fact that stimulus d throw
and react, which made me quite happy because I know
to react.

Speaker 3 (22:33):
That's how you realize that.

Speaker 4 (22:36):
And yeah, the other thing I found quite interesting, purely
from a selfish point of view, was how people learn
Drew Andrells, because obfullly I've written a book as well,
so I found it quite interesting to just see how
people learning. And it's interesting to see that more people
kind of watch videos and tutorials rather than read book

(23:00):
or something like that, because yeah, I guess horses for
courses and stuff, but on I prefer text based rather
than video. But it's it's always interesting to know like
what other people are preferring, especially if you're trying to
sell an educational product. So those are a couple of

(23:20):
things that kind of I found particularly interesting out of
the results.

Speaker 2 (23:25):
Quick quick thought on that one when it comes to
like the I think that's an interesting thought there around
Like you read books, I skim books.

Speaker 1 (23:35):
I'm not.

Speaker 2 (23:36):
I think I'm actually slightly dyslexic, and so I'm not.
It's always been really difficult for me to get through
a lot of text based things necessarily. But one of
the other questions we did ask so it was like
what types of education and content helps you learn most effectively?
And video stuff was not It's like the fourth I
think it was like tied with books.

Speaker 3 (23:55):
So most people said that they find blog posts.

Speaker 2 (23:58):
And like the Rails guy, it's to be the most
effective way to learn.

Speaker 3 (24:03):
But they're consuming a lot of videos.

Speaker 2 (24:05):
So it's like it's is there are they learning from
the videos or are they just spending more time watching
videos and because it's an easier way to consume that information.
Maybe I don't know, but video is an interesting one,
but I don't know. Again, this is what the people
are kind of reported, so it's all they're all really
closely kind of aligned in the stats as well, So

(24:27):
like there was no I think huge prizes to me there,
but otherwise people saying that like working on you know,
the documentation and things like that. So which is I
think A good good thing that came out of this
was like the the Rails Foundation, like Amanda them, they
had I know that they.

Speaker 3 (24:44):
Were working on a number of projects related to.

Speaker 2 (24:48):
Video content and the new guides, like redesigning the way
that all looks and revisiting a lot of the content there,
and so there's a lot of energy trying to be
on like let's do video, let's also do this. We
kind of like have to come out of from different
persons because there are just people do learn different people
learn differently, and so it's like, how do we make
this this as inclusive as possible.

Speaker 4 (25:12):
Yeah, I'm looking at that question now about learning most effectively,
and that's interesting. I wouldn't have expected that that mismatch there,
But I guess like for me, we're personally with videos,
I tend to zone out sometimes and then I'll come
back a minute later and like, Okay, crap, I've forgotten
to rewind and watch this again. And then you can't

(25:32):
command f a video. So that those are my two
biggest gripes.

Speaker 2 (25:37):
That's true, you can't. I mean in the same way
like I was reading a book last night and before
I went to sleep, and I was like, got two
pages and I'm like, what did I just read? I
have no I've seen the words. I don't know what
I just read. So let me start that again. But
you know, it's interesting. Live streamers came two percent of

(25:57):
people find that the most effective way to learn, or
or podcasts, and so our podcast educational or they media
consumption or you know, it's this kind of like auxiliary information.
But maybe is this an educational platform. I don't know.

Speaker 1 (26:14):
I think it depends. One other thing that I wanted
to point out was that I think a lot of
newer folks are going to lean more toward video casts
and books and maybe the rails Guide some I think
as you get more advanced, you start looking more at
the blog posts and documentation and maybe podcasts to just
give you kind of here's what's the latest thing that's

(26:35):
out there. That that was kind of what I got
out of it, And so I think you had a
lot of experienced folks that they don't need as much
of the walkthrough on some of the stuff that's out there,
and maybe they're reaching for the documentation and stuff instead.

Speaker 5 (26:54):
I feel like this is one of the hardest categories
to extract something meaningful from the survey, right, because like
I feel like learning, like you do kind of like
pick a variety of different things to like build up
your learning material and maybe different ways that you do
you don't think about and how much they impact you too, Right,

(27:18):
Like I remember like really diving hard into reels guides
when I was first like looking at stuff and like
doing the reels casts, but there was a bunch of
other stuff that was I was also listening to Ruby
Rogues at the time and like a bunch of other
podcasts that just like try and stay up to date, right,
And how much does that.

Speaker 6 (27:35):
Influence your learning ability?

Speaker 5 (27:37):
Right, and like just being able to adapt to the
material that you're learning. It's like almost like that, you know,
reflective learning that like helps like harden and make things
stick a little better.

Speaker 6 (27:51):
And so it's like I always look at the survey.

Speaker 5 (27:53):
And like wonder, like, you know, how do you are
we capturing everything?

Speaker 2 (27:58):
You're right? And I think it's always like how do
you try to contextualize this in a way that's these
are not like conclusive, you know, like we didn't ask
people like prove it, you know, prove that this is
how you learn most effectively. It's like it's like in
the moment type of like responses that we're getting, So

(28:18):
we how do we read the tea leaves a little bit,
I suppose, but it's not.

Speaker 6 (28:23):
It's almost like what they remember most that they think worked.

Speaker 3 (28:26):
Best and recent. Yeah, right, it's still important.

Speaker 5 (28:32):
I'm always fascinated about the section though, Yeah, because it does.

Speaker 6 (28:37):
Change a year after year two quite a bit.

Speaker 1 (28:42):
Yeah, a couple of other things in the learning.

Speaker 2 (28:44):
I was gonna say that one of the one of
the things I was and I haven't got I didn't
get a chance to go like pivot the data to
too much on this particular one, but the because you know,
we're able to look at like how long people have
been working.

Speaker 3 (28:57):
With rails and then try to look at the data for.

Speaker 2 (28:59):
That, and like if I had thought ahead more, I
could maybe got some more interesting details for that. But
the I was thinking one of the one of the
things is that we know in the community is just
that you know, this was also conducted you know, late spring,
early summer ish last year, summer last year, so twenty

(29:19):
twenty four, and you know, there was a lot of
layoffs in the year prior. There's not a lot of
junior developers getting hired in the community. Coding schools kind
of a lot of them closed. We used to I
used to know that one of our strategies in the
past to ask questions to people was to hit the
some of the coding schools. They that would get shared

(29:40):
around some of them, you know, some of those developed
some of the developer they would share with their their
you know, their their recent graduates or previous graduates. They
would share it, you know, like here filut the surveys.
So so I think there's like data. I think we
got a good capture of people that are actually working
with rails right now and not too so that I
feel like that's interesting, but we didn't really they also
have maybe as many junior people participating or maybe because

(30:04):
there's actually just last junior developers, uh coming into the
into the market in the last year or two prior
to the when we conducted this particular survey this time.
But so, I don't know, it's kind of it's it's
always a little bit interesting to see how that data
fluctuates a little bit, but also by how little it
changes sometimes too, there's a lot of the data that's
like we're looking, I'm like, how did Linux usage didn't

(30:24):
move like like more than like a percent or two
And I'm like what how despite you know, like DH
is talking about it all the time or something. So
it's just like, I'm like, how does this not move
a lot more?

Speaker 1 (30:36):
Omacoub Yeah, so Valentino, was there a section that step
to you?

Speaker 5 (30:46):
Yeah, I'm always fascinated to see, uh, kind of like
I usued, you know, where the front end stuff shifts,
because that's definitely the thing that changes the most, I
would say over time.

Speaker 1 (30:57):
Mm hmm.

Speaker 5 (30:58):
So it's it is interest seeing to see stimulus rank
so high personally, and maybe that's just because I've been
stuck in a very fixed front end for for so long.
Maybe I just don't see the underpinnings there, But it
is interesting to see the stimulus adoption over time just

(31:19):
get such great support.

Speaker 1 (31:23):
Yeah, it's it's awesome if anyone's looking to figure out
how to do stimulus with rails, I can't recommend I
used this book highly enough. So yeah, I mean, on
that note, though, I did notice it like you still
got React, jQuery, View and next JS and Angular JS

(31:45):
is kind of the next five and then you get
to an Alpine JS, which is a minimalist framework kind
of like stimulus. So of course then I kind of
laughed because I saw backbone and handlebars on here too.

Speaker 2 (32:01):
These things don't go away, No, they don't. Well, a
lot of I mean and something I gave a talk
at Rails World about dealing with like techno debt and
rails applications a lot of things, and like a lot
of projects have multiple job as script libraries in them
because there's a tendency to, hey, we want to work

(32:22):
on this new set of features. This might feel like
a perfect opportunity to experiment with that new framework we've
been itching to play with, So let's use it over here.
And so they'll add it and they'll start working on
the new functionality, new features because it's easy to sneak
it into that with the product and like, okay, we're
going to do this over here, because it's a lot
harder to sell them on retrofitting some existing stuff. And

(32:44):
so they do that and they kind of like the
first project or two that they do is kind of
like they're trying to learn on the job type of thing,
and they're like, well, we learned some stuff, and like
the next time, well we'll come back and refactor it.

Speaker 3 (32:53):
And maybe they do or you don't.

Speaker 2 (32:54):
And then a year or two later they're still working
on this stuff, and then they introduce another one, and
then there's another one, you know, then they like, well,
we'll keep the admin area like this in this area,
and then we have this other new section.

Speaker 3 (33:04):
We'll use this thing.

Speaker 2 (33:06):
And so then you've got like three or four different
frameworks in your your your your rails application ecosystem, and
you're like, well, which one is the better one. It's like,
is it the newer one or is the one that
people complain about the least. And so one of the
things that I've been advocating for teams to consider is,
I dare you too, If you really want to use
that new thing, do it on your existing stable features first,

(33:28):
because you should already have really good healthy test coverage there.
And if it doesn't work and you're not figuring it out,
you can just get reverted and things are still working.
But try to force yourself to implement it on existing stuff.
If that's too hard, I guarantee it's not going to
get easier two years from now to do that make
that change.

Speaker 3 (33:47):
You're just going to stick with it, and you're going
to have this.

Speaker 2 (33:49):
Problem where you're not able to upgrade different things or
you got all the job ascript chaos going on on
your front end framework. So easier said than done. But
I that's that's that's the thing that I'm trying to
pitch teams to try to consider doing is like, take
a hard look at the do the hard thing.

Speaker 3 (34:07):
If you're not only to do.

Speaker 2 (34:08):
It, stick with the framework that you're already using, because
that's you're going to be stuck with it anyway.

Speaker 4 (34:13):
So I'm always quite reluctant to try and rewrite features
that already exist using something newer. So, uh, well, I
completely agree with your approach. You're trying to introduce something
new to some the feature that already exists. But where
what's the judgment called the how do you decide that

(34:33):
this is a new thing that we want to try
and we're going to rewrite something that already works against Well,
that feature already works. I don't see why we should
spend time rewriting it using something new.

Speaker 2 (34:45):
I think the typical developer answer It depends. I think
the the challenge there is, especially with soft some projects
where you know that they're your team's already starting to
divest themselves, and so it's interesting. I'm a big, a
big advocate for not rewriting, and so like, well, I

(35:07):
guess I'm advocating for like micro rewrites you know, in
certain areas. And so it's just why do we treat
like a front end framework differently than we would with
like say a Ruby gem that's no longer going to
be supported, we need to migrate that. And so if
the lift is so high, then I feel like we're
already admitting that the front end is just going to

(35:30):
be too much of a mess. That like we're when
we make a decision, we're making a really long term
decision with this, and how how can we approach that
a little bit more? Like are there ways for us
to refactor parts of it, you know, like or rebuild
parts of it and figure out how to glue things
together like I've I've you know, work with a number

(35:50):
of teams that in the consulting capacity where they've done
like these migrations where they're moving from Angular to react
or something, you know, because Angular one to Angular two
was necessarily like a good upgrade path for a lot
of people, and so that could happen with any of
the frameworks that you know, we talk about. There's always
a chance of that happening. But for these existing stable features.

(36:10):
It's just more of like, if your team's trying to
experiment and learn, just learn on something you already know
how it's supposed to work from like a user perspective,
and like can you experiment with that and test out
if this idea is going to work well before you
start building on some new ideas and learning on the
job with that new framework, because a lot of these
new frameworks don't necessarily have a lot of good documutation initially,
or they have some documentation, but there's not a lot

(36:31):
of real world experience yet. So you're learning, you're sharing
as you go. But that's but the story of the
front end has been we're all learning on the job
and it doesn't get it's been difficult to go back
and clean things up. So I'm just trying to like
a maybe advocate for like maybe there's a different can
we experiment with some different approaches, because that has been

(36:52):
the go to approach. You don't break the existing stuff
because it works great, but if it's but that's a thing,
if it's going to break, how do you make it
less breakable?

Speaker 1 (37:04):
And so.

Speaker 2 (37:06):
I don't this this is the heart, This is the
hard part. Of our job, I supposed to try to
figure this stuff out.

Speaker 1 (37:10):
So, yeah, it reminds me a little bit of a
scientific experiment, right, So you have these studies that are
done right, and so they have the control and then
they've got kind of their experimental set. And typically the
best practice is is you only change the thing that
you want to see what difference it makes. Right, And

(37:31):
so if you're doing a new problem and inventing a
new solution and using a new tool for it as
opposed to doing a well understood problem that's already been
solved with the tool you already have, yeah, then you
have a real good comparison to see where where the
trade off is.

Speaker 2 (37:50):
You might find that, you know, if you're just rebuild
like a small part of your application or front end
with a different jobs, you might be like all those
assumptions we made of this was going to be way better, Actually,
like it's got some weird things that we didn't quite realize,
And is that trade off going to be okay for
us in the future or because then because I think

(38:10):
the question is going to be you start, you're using
that new thing on the new functionality, are you ever
going to go back and rewrite that stuff or are
you saying that those existing stable things are just never
going to change. So that's why you laugh about like backbone, Like,
there's plenty of projects out there that are running just
fine with backbone. We work on projects like that, and
I can tell you we tried to do a project

(38:31):
for one of our large clients that was the client
was like, yeah, we want to move to react from
the backbone, and we were working through this big rewrite
on the front end and eventually we agree, like, you know,
this doesn't feel like it's we're this doesn't feel like that.
I don't want to value to your business necessarily, but
this is fine. But yeah, we're probably you know, they're

(38:52):
like they decided they're going to end up life that
particular project anyways, and then a year choose so we
you know, we hit the.

Speaker 3 (38:58):
Brakes on that particular project. But those are.

Speaker 2 (39:03):
If where is the future of these projects going to be?
And like how where do you want to kind of
sit with that? And again it's a difficult part of
our job, I suppose, But.

Speaker 1 (39:14):
Yep, all right, I'm going to hit one of these
areas that I was interested in. I'm going to talk
a little bit about deployment and DevOps. I would have
picked things like Ruby and Rails versions, but it seems
like the majority of people are close to, if not

(39:35):
using the latest thing, and so I was just like, oh, okay,
good yeah. So yeah, So a couple of things. One
is what deployment tool do you use? And the other
one was how often do you deploy? And I've always
wondered because I haven't really looked at surveys like this
that often, you know, are people really doing kind of

(39:57):
the continuous deployment and then they're deploying off or are
are you know, people mostly on a we're going to
release after our sprint or we're going to release after
our you know, after our big set of whatever, right,
which is always painful whenever I've done that places I've worked.
But it looks like the majority I shouldn't say majority,

(40:21):
but a large number of people are deploying every day
or every week. I mean it's thirty seven percent for
every day multiply multiple times a day, and thirty six
percent for multiple times a week, which to me says
that they're doing it, you know, possibly several days during
the week. And so yeah, I mean that's like what

(40:44):
seventy three percent, So that I thought that was very
very fascinating.

Speaker 2 (40:50):
Yeah, it kind of surprises me when we'll we'll have
client engagements will come in to do some consulting for
a short period of time, and those those are one
of their usual questions we ask. It's like, tell us
about your workflow for pushing stuff out. And then there's
the companies we talk to. You are like, oh, yeah,
we our team deploys.

Speaker 3 (41:08):
Hundreds of times a day.

Speaker 2 (41:09):
You're like, what, okay, so there's that too, the extreme
of like oh yeah, like every three weeks we push
out a thing. You know. I'm just like, okay, that
feels like unless there's some like seven one issue type
thing we need to push out, like a quick bug
fix or something there's like a huge issue going on.
But otherwise they're like, we don't. And I think it's
always contextual also, like you know, way to pivot. That

(41:30):
would be like if there's a lot of restrictions in
their particular industries, like maybe it's healthcare for example, or
with companies and healthcare, some companies like they have very
very rigorous process around that because they have to be
able to have an audit trail that they can report
to the governments or something. So it's a lot of
weird things that can kind of change that. So then

(41:51):
I'm always curious about how they then have to deal
with as a development workflow Q things up for a
bigger bulker release versus having a lot of like these
micro small things they can get shipped out. I think
it depends on you know, the context, context of that
particular business and industry or and a lot of people
just being really you know, concerned about breaking things, like

(42:14):
if they have a really brittle environment, they need to
really rigorous QA process before they push things out or not. So,
but yeah, it's it's it's a lot, it's it's it's
encouraging because I remember, I think if you go back
several years that I think that the data for that
would be like much lower. It would be like maybe
you know, weekly would be like a pretty common thing
or something.

Speaker 1 (42:34):
But yeah, the other one I thought was interesting was
this was the first one where Camal was listed as
an option for deployment tools, and then there was one
continuous deploy R. I don't know if I've even seen
that or was that just a no, it's continuous deployment.

(42:55):
It must be cut off.

Speaker 2 (42:55):
Oh yeah, it's truncated and graphic chart. Yeah, end issue.

Speaker 1 (43:02):
Yeah, you've got get and Capistrano. And I don't know
what people mean by get. Is that like a get
pushed kind of like Heroku or yeah.

Speaker 2 (43:10):
I think yeah, it means which is these are some
of the I feel like there's always a really awkward
question because we've kept it in because people will if
we just limited the set of things, like people will
type in other.

Speaker 3 (43:22):
They'll they'll write things in, so they'll we.

Speaker 2 (43:25):
Just I think a lot of people don't know the
difference between pushing too so there, but I think a
lot of that comes down to, like, yeah, like Heroku
is just like get pushed and then pushes to Heroku
without explicitly just saying they're deploying to Heroku.

Speaker 1 (43:39):
Yeah, so yeah. It said two point four percent of
people reported using Kamal, which I love Kamal. I'm curious
to see next time you do this when you ask
about what proxy and web servers people are using, to
see if Kamal proxy comes in on the list. Because
traffic was the default Kamal, one and two hundred and

(44:02):
three people said they were using that and so yeah,
I'm curious to see if that switches up.

Speaker 2 (44:09):
I would imagine, but you should see.

Speaker 1 (44:12):
Yeah, and Thruster was another piece of that puzzle too,
that's on there.

Speaker 2 (44:19):
Yeah.

Speaker 5 (44:19):
I'm curious too, like how many people like use chat
ops still, Like is that still the go to deployment
for larger organizations.

Speaker 6 (44:31):
I'm curious, like do you.

Speaker 5 (44:32):
Do like a lot of like you know, cross referencing
post survey, like to see if like some things are
related like interdependency, like you know, the their team size.

Speaker 6 (44:45):
Is related to how they deploy or x y Z.

Speaker 1 (44:49):
That'd be interesting.

Speaker 3 (44:50):
Yeah, we definitely could.

Speaker 2 (44:52):
It's just how much we've historically would share all the
results with everybody and we just need to put together
especially for that, and we just kind of shipped up
before we had a chance to do it this year,
so people can kind of play around with the data
there because there's a little bit of data scrubbing we
have to do for our privacy stuff there. But the
definitely something we can definitely expose for for folks. But

(45:13):
what we found is what we've done in the past,
like five people would download this and then so we're
like how much how much time am I putting into
something for those five people, but there is there is
some there's some ways to do that as well.

Speaker 6 (45:25):
You got to hook it up to an AI chat
to make it easy. Related.

Speaker 3 (45:31):
Yeah, and I hope that I hope that it's accurate.

Speaker 2 (45:33):
Yeah.

Speaker 1 (45:36):
Deploy GPT.

Speaker 4 (45:38):
Yeah, if you've deployed applications using other languages or frameworks,
would you say that it has been easier or harder
to deploy reels applications? And sixteen percent said it was harder,
but forty five percent set was easier and thirty nine
percent said it's about the same, which I found interesting
because I've done a little bit of PHP eight years ago,

(46:01):
and when I could, I found it quite easy to deploy.
I can't remember exactly what I did was years ago,
but it was like I didn't really know the next admin.
I still probably not that good with the next admin anyway.
And when I came to try and deploy a rails
app for the first time, which is something about five
years ago, I started using the word to live, I

(46:25):
cave and had to use cloud sixty six and even now,
like I would say that like a render dot comfort
for hosting, but if I had to do like a
bare bones vps. Any Ruby, not just Raels has to
deploy any Ruby web app, but it wouldn't be as
easy as I as I like. So I just found
that response interesting because I don't know, I mean, do you

(46:48):
think do you think people responded easier because of things
like render dot com and Heroku?

Speaker 2 (46:54):
I think yeah, I mean I think that's very much
the probably very much the case for a lot of people.
And we definitely could look at pivoting the data data
there to see if you can get some more detail
on where people are hosting those applications. But it's interesting,
you know, that experience you had coming from Php to Rails,
Like I shared that experience early on because but that

(47:16):
was also why part of what we did from a
company was offer hosting services to make that easier. Because
it was so much easier to host a PHP application
because you literally just uploaded some PHP files and maybe
you needed to restart the server maybe usually.

Speaker 3 (47:33):
Not back then wasn't such a big deal.

Speaker 2 (47:36):
But rails, you know, you were like, well you got
to run like a little Rail server, and so that
that's running behind like your web server, and YadA, YadA, YadA.
And then but things like Capistrano did smooth that out
at one point, and Heroku made it a lot more
accessible to easily quickly deploy so you didn't have to
learn how to manage your own Linux server out there

(47:56):
on some you know, rack space or wherever you're hosting
your your vps and stuff like that. So I hear
you on that, is it harder or easier? I think
it's To me, it feels like a lot of I
think it's because that like a lot of people are
like it's like thirty nine percent that it's about the same,

(48:18):
you know, it's a little less than half and so,
but harder. I think it depends on how complicated a
hosting environment are, because the other things I think it
related to deploying is also like being able to debug things,
and I always feel like I feel like one of
the things that I really appreciate about Ruby on Rails
early on was how easy it was to but debug

(48:39):
things in production versus with working in like say PHP,
because we had things like you could essensation into the
server and then run Rails console and do stuff and
you're like, oh, this is amazing, and like didn't feel
like we had that kind of functionality at the time.
There's tools like that now, but that stuff was just

(48:59):
kind of like a for my professional development growth. That
was like a huge like aha, I'm like, look what
we can do and like. But you also had to run,
you know, all these different separate processes and you're spinning
up delayed job things or whatever, men cash and all
this stuff, and you'd have to run all these little
services in parallel on a server. So there's a lot
more things related to your rails apps that you have

(49:20):
to run as well.

Speaker 3 (49:21):
It wasn't just like PHBD, like you.

Speaker 2 (49:23):
Run the thing and then you had a database or
something you connected to and then that was the bulk of.

Speaker 3 (49:27):
What you needed to worry about.

Speaker 1 (49:29):
So yeah, I think some of the tools have gotten better,
like you said, but with Kamal, I mean you just
you set up the vps, make sure you can have
to state into it, and you know, so do run
things as route and then you just tell it to
set it up and then you tell it to deplay it.
So yeah, I mean, depending it Yeah, a lot of

(49:54):
it depends on how your system set up. But what
I found is the tools just keep getting better and
better and better.

Speaker 4 (50:00):
Yeah, Comal. The only thing is it's it's Docker, and like, yeah,
it's I just find it too heavy handed for the
kind of stuff I do, not not for my clients work.
My client work obviously is high enough scale to warrant that,
but stuff I do on my own, I just find
like Docker to be a bit too heavy for that.
So I'd quite like just a simple solution that isn't docerbase,

(50:24):
and I'm playing around with some stuff. One thing that
I'll be quite interested in this year over the probably
this year and next year is if the adoption of
Falcon goes up at all, because that's kind of designed
to be like all in one server, Like you don't
need to have engine X, a caddy or something in
front of it. It's it's meant to be like, uh,

(50:48):
right in front of your application, and it's meant to
be like it's meant to work as a sul termination
and just work as a web server. So it should
hopefully reduce the number of moving parts you need for redeployment.
It would be good to see that kind of beIN
a little bit more traction, I think.

Speaker 1 (51:07):
Yeah, Robbie, was there a section that stood out to
you that we haven't talked about.

Speaker 2 (51:13):
Yeah, some of the things that I've always found interesting.
The track is because it's just having been a part
of the rail's ecosystem for such a long time and
is a lot of the third party services and tools
that we're using. So, you know, this was the first
time this last year was the first time New Relic
wasn't number one for performance monitoring and the rails ecosystem

(51:36):
since we started asking that question. I think back in
I think Data Dog took over the number one spot.
Otherwise New Relic had been, you know, the and I
think that I don't want to I mean, I know
a bunch of people that work on New Relic, but
they've that company is going to have been bought and

(51:57):
sold a couple of times at this point now. But
the so it's been interesting to see that kind of
evolve into seeing how like Century and ap Signal have
kind of like jumped up a little bit more in
the community there. And I always it's to me, it's
always kind of fun to watch like the big companies
and the small companies trying to like I don't feel
like that space has ever like been terribly stable for

(52:18):
a lot of companies, necessarily outside of like the people
that are at the top there, and so like we
get aer tracking things and as well, so like I
think on the aeroor tracking, you know, centuries top been
the top of the last three times we've run the survey.
But it's been interesting. For whatever reason, I've always been
fascinating with those particular those topics to see what people

(52:39):
are using, and because I feel like it's really easy
for teams to quite often switch and experiment the different
thing we come into consulting engagements. Well, like we just
just actually just recently, we're working with a company doing
a code at it and giving this doing some consulting
with them, and we were logging into the new relic
where they've been tracking their errors for a really long

(53:00):
time and we're looking all this stuff and they're like, yeah,
we don't really log.

Speaker 3 (53:03):
In that offen and go look at the error stuff
that often we.

Speaker 2 (53:05):
Just occasionally I'm like, well, maybe a really easy thing
to do is just to switch to a different platform
so you have some new data, new fresh data set rather.

Speaker 3 (53:14):
Than just ignoring the old thing, and like you can
use my U.

Speaker 2 (53:19):
So they got set up with like app signal like
in an afternoon and you know, maybe made a confute
a few co changes to make that work, and then
it just kind of revitalized the team a little bit
to start paying attention to that stuff a little bit
more thoroughly. And so that's always kind of a nice
thing to be able to know that there's other tools
that you can kind of play with and maybe get
a different perspective or look at your data and you're

(53:40):
the activating your applications from a different perspective, and so
maybe switch over to honey Badger for six months and
try that for a bit and see how that maybe
rethinks your how your team approaches this stuff. Those are
like usually pretty easy things that teams can do to
just get some new energy around something rather than being like,
let's log into the thing. We don't really pay tension
or I don't really like.

Speaker 3 (54:02):
The UI or all the upsales that they're.

Speaker 2 (54:04):
Doing and not trying to pick on new relic or
data Dog or whatever, or like people like yeah, data Dog,
they as soon as we sign up for account with them,
all over. Developers start getting emails and phone calls all
the time from their sales people trying to upsell, and
you're just like, yeah, that's going to happen with this
bigger company, so other things that I know interesting around
just seeing things like what debugging tools people are using,

(54:24):
because there's you know, there's new things popping up, and
like Ruby Ruby de bug is what sixteen percent now
and you know the prize at thirty one percent, and
so I think if you're just people, like a lot
of people just keep using the same thing that they're
already used to using for a long time. So I
think it's sometimes it's just helpful to be aware of
these things counterpoint. And you know, you mentioned like the

(54:47):
Ruby versions or we would ask you know, which which
version or Ruby you're using, not not just like the
number version, but if I're using like Matt's is Ruby
versus j Ruby things like that, and let me see
if I try to remember what the question is, but
I got I'm not trying to point out unnecessarily, but

(55:08):
we ended up because the data from from the survey
the previous years that jay Ruby was so low in
number of counts that I'm like, I don't feel like
it's important to keep is that even an option for
people to check anymore? Because there's another box and let's
just let people type it in and then that didn't
make someone all that happy that I removed it. I'm like, well,

(55:29):
I'm not seeing people can't do that. It's just like
there's this insignificant number point that I'm like, and they're well,
this is like a So some people see these these
are the types of surveys as an opportunity to highlight
that there are these other tools when they're picking the
survey that they could be exposed to. So I'm like,
I can't list every single jam, every single.

Speaker 3 (55:49):
Third party service.

Speaker 2 (55:50):
It's just like we got to kind of do our
best to try to encounter like what do we know,
because there's a lot of things about the community and
the tooling that we don't even we're not even aware of.
So this is when we I'm usually learning about anythings,
like oh, what's this falcon thing? You know I've heard
maybe mentioned, but like a bunch of people are using it.
I'm like, I didn't even know anything about it. So
that's always kind of like a fascinating part of the

(56:12):
surveys too. It's it's it's it's it's it's easy. It's
not easy to get a lot of people to felt
the survey, but it's an easy way for me to
learn a lot about what people are up to in
the community, so kind of selfishly, yeah, I always wish
there's like a Ruby toolbox for like services, you know,
Oh everybody's using this or what is this? You know?

Speaker 6 (56:35):
Uh, yeah, I don't know. I feel like that is
kind of missing.

Speaker 2 (56:40):
It's a fair point. If anyone listening wants to create
a some sort of project to do that, I think
that would be good. But maintaining that keeping an updated
this is another thing.

Speaker 1 (56:55):
So yeah. One thing that I picked up from the
survey that I didn't know existed was in the version updates.
It said, is your team using a dual boot strategy
for upgrades? And I was like, wait, you could do that?
So I had to go google it.

Speaker 2 (57:11):
Did you learn much about about that? That said, there's
a couple of really good tools for that that'll be used.

Speaker 1 (57:16):
I found a gem that does it, and I didn't
get much further than that.

Speaker 6 (57:19):
But I'm surprised that the boogoot gem.

Speaker 1 (57:23):
That was from shopify someone that I found.

Speaker 5 (57:26):
I'm surprised that after all the conference talks about it,
that hasn't gotten more adoption.

Speaker 6 (57:33):
It's not that hard.

Speaker 1 (57:35):
Yeah, I'm working a project now. That we have some
performance issues, that there are tools in rail seven to
two that are not in Rail seven oh that we
want to use, like common table expressions and the way
we want to do some of the things with those.
So yeah, I was like, huh, well, maybe we can
use this over there and see how far we get.

Speaker 2 (57:58):
Publish this back in right right before world So I'm
trying to remember the things that we're kind of like
capturing my mind at the time. But the the other
part was just like the just reinforcing the monoliths, I suppose,
and like that the number of people that are focusing
building a lot of micro service has been trending down

(58:20):
for the past I think like last three surveys, so
say six.

Speaker 3 (58:23):
Years or so.

Speaker 2 (58:24):
So that's been something that's been interesting to see that
there are and I know that there are a number
of teams just from doing consulting and talking with different
companies that are consolidating a lot more stuff and trying
to do more monolith Their app or at least have
to be a bit more hybrid than like because they're
teams shrunk and it's a common pattern that like we

(58:46):
make a lot of decisions as teams assuming that especially
for hired during a growth period that we just assume
that the team's going to continue growing. And then so
how do we architect our system to support maybe a
one day larger team. And we don't often make a
lot of technical decisions with the assumption that we're going
to be a smaller.

Speaker 3 (59:06):
Team in the future. And maybe that's actually an ideal
state for that team is to be smaller.

Speaker 2 (59:12):
So how do you weigh kind of weigh those two
things up, Like, we don't we may not need the
team we have today in two years to support this thing,
and that's maybe ideal. Whether the leadership is talking about
that out a lot or not, that's maybe another issue,
but that is like a thing. And so like, I
know a lot of like really really small teams. I'm
talking like two or three people that are working on

(59:33):
software projects that I've got like twenty five micro services
and you're just like, I'm like, this doesn't seem fun.
How many rails upgrades are you doing? And like, okay,
well we did this when we were ten people. I'm
like all right, and then and like and most those
people aren't even here anymore. So you're just like, okay,
well this is a fun thing to kind of re

(59:53):
reconfigure and rethink about how you reframe this stuff, because
like we had to make a change, and we now
we got to make a change in three different repositories.
Figure out the deployment process, scheduling because like these are
not this this, this doesn't feel super efficient. And it's
some very similar to the front end framework type of
issue as well. But micro services and the monolith thing,

(01:00:14):
I think it's so monolists are on the rise in
terms of people trying to keep it keep it in
like one repo as much as possible unless you really
really need to start putting some stuff out.

Speaker 5 (01:00:27):
I'm curious how much of that is thanks to pop packwork,
because that seems to be a common pattern. Is like
making micro services in your monolith with packwork, which seems
to like solve kind of both problems that people face. Uh,
and the people that want to push for micro services
feel at ease because it kind of feels like a

(01:00:48):
micro service in a way. I don't know what you're
what your thoughts are on that.

Speaker 2 (01:00:54):
I know that I Aleen gave a talk at Reil's
Word about that, and it was kind of a little
bit critical of doing a lot of that because there's
very because often the boundaries are not so clearly defined
and people are like stuff is overreaching all the time. Anyways,

(01:01:14):
I don't know that she felt like she had like
a good way of solving that necessarily, but like I
think her perspective is like we might.

Speaker 3 (01:01:22):
Have over we're still over.

Speaker 2 (01:01:26):
Separating in a way trying to optimize, and it's causing
other sorts of issues with like ownership within projects and
feeling like how did how did just teams.

Speaker 3 (01:01:33):
Work together own projects? Is I think another part of it.

Speaker 2 (01:01:36):
So there's the human part of that, and then there's
the technical approaches to solving some of that stuff and
like trying to weigh that up when the teams are
maybe not always going to match the technical separation of
those concerns and so I know, it's it's it's it's
it's tricky. So but yeah, packwork is definitely an option
there for kind of approaching them.

Speaker 1 (01:01:58):
Yep.

Speaker 5 (01:02:00):
Yeah, I like to try ways from uh just like
the open ended comments was, uh, you know, move away
from over engineering.

Speaker 2 (01:02:09):
Things optimize for a smaller team, And I think even
if it's the same size team, like if you can
make this your software project easier for when half of
your team is on vacation to maintain, Like, wouldn't that
be a good thing? Wouldn't that feel better? I just
think there's probably a lot of things that we could

(01:02:32):
be asked for, so like like like especially with like deployments,
is you brought that up as an interesting thing, like
there was a time when, like we've I think there's
a lot of benefits. And one of the interesting things
about why Camal's resonating with some teams or some small
teams in particular, is that it feels like it's giving
back some control to the developers a little bit because
I think within this era where there's a lot of

(01:02:54):
emphasis on you know, DevOps type roles and people, there's
some specialization that came about, you know again, and so
we've this was a very similar pre you know, go
back to.

Speaker 3 (01:03:07):
The early aughts.

Speaker 2 (01:03:08):
We had a lot of DBAs you know, in our
in our teams, someone that would manage the database and
be the guardian and the gatekeeper for adding new columns
your table, adding new views or soot procedures, and the may'd
be the ones who managed that. And we were able
to kind of take some of that and like, no,
we can do this ourselves. We can we can manage this.
And then I think over the last decade or more,

(01:03:31):
we the infrastructure has got more complicated as we've moved
to the cloud, and we can do all this stuff.
And so we have a lot of a lot of
really large teams really need to do with a lot
of scaling things. A lot of small teams have some
scaling issues, but they would then adopt a lot of
the same approaches that large teams are talking about because
and so a lot of developers are actually so I

(01:03:51):
think back to the question about is it harder or not?
Is like some people work in environments like and actually
not responsible for anything but pushing to a branch and
then some magic happens. But ask me to change that.
I don't even know where to start. What is this
terrorform stuff, this cooper net?

Speaker 3 (01:04:06):
What is this like?

Speaker 2 (01:04:08):
How does this stuff work? I don't have time for that.
I'm going to focus on rails and I think that's
okay in some teams. But it's been a challenge for
a lot of developers to feel like I can make
changes or I feel it feels very brittle at times
because there's some magic stuff that's happening over here, and
I don't.

Speaker 3 (01:04:22):
Want to break the infrastructure.

Speaker 2 (01:04:25):
So infrastructure became a challenge and kind of like just
to kind of come back to this is just so
those a lot of teams don't feel like they can
make those changes. So teams are a lot bigger more
because there's just people that are specializing in certain things.

Speaker 3 (01:04:38):
And you got that.

Speaker 2 (01:04:39):
Now you have that weak point of like what happens
if that infrastructure person leaves or you need to keep
them around, and maybe they're not the best person to
be part of your team. And so I think there's
like a little bit of things like comal kind of
like pulling that back a little bit, like we don't
need all that stuff for a lot of software projects.
We can do that, but does every project need to

(01:05:00):
be deploying every single commit.

Speaker 3 (01:05:05):
Automatically? Like that's maybe I don't know.

Speaker 2 (01:05:10):
Maybe maybe you could just wait till someone runs in
the command once a day and that would be fine.
But there's gotta be some trade offs there because you're
spending a lot of money on infrastructure stuff and all
of those get up actions running or whatever you're using
for all that stuff. But that is costing your company
money to do that stuff and it's not free, so

(01:05:30):
figure out how to balance that.

Speaker 1 (01:05:33):
Yeah, all right, Well we're kind of getting to that
point in time where we go to picks. Before we
do that, though, Robbie, if people want to connect with
you online, or they're thinking maybe they have a project
where they need help from someone like Brent planet ar Gone,
or they want to listen to the maintainable podcasts, where
do they find any of that stuff?

Speaker 3 (01:05:51):
Search for it?

Speaker 2 (01:05:51):
I mean, you know how to do this stuff.

Speaker 3 (01:05:54):
Links.

Speaker 2 (01:05:54):
I'm sure there will be some links in the show
noteswer I'm Robbie, Robbie Russell or you can find me.

Speaker 1 (01:06:01):
All right, good deal. Well let's uh let's do some picks.
Are you sh you want to start us off picks?

Speaker 4 (01:06:07):
Yeah, that's uh. So she got back from New Zealand,
so I'm just gonna New Zealand as a country. That's
gonna be one of my picks. It's just them, It's
it's probably our favorite place to go on holiday. I
was there for like six weeks and yeah, the place
feels fictional.

Speaker 2 (01:06:24):
Man.

Speaker 4 (01:06:25):
I went did also, I went to hobbiton so I
got got this thing from from from hobbiton, which is
a I don't really do bucket list, but if I
had a bucket list, I would probably be on there.
Uh yeah. It was also nice to just get out
of the British winter for a bit. But near New

(01:06:45):
Zealand as a country is one of my picks. And
then I got back and I binged a new TV
show because that's what I do. It's called A Man
on the Inside starring Ted Dunce and it's Michael Shaw's
new comedy known for other shows like Parks and Rack
Brooklyn nine nine in the Good Place. So his new
shows as like, what's only eight episodes to spend an

(01:07:07):
evening and binge the whole thing. Very funny, very enjoyable.
Recommend that. And I'll finish off with that technical pick,
which is the acinc container gem by Samuel Williams. I
have the chance to hang out with him while I
was in New Zealand, and one of the things we
kind of played around with was the acink container gem,

(01:07:31):
which it's kind of just a way to like orchestrate
roovy processes. So instead of like packaging everything after the
darker container, you just have any acinc container manage all
your different processes, and it kind of deals with restarting
and blue green deployers and all that kind of stuff,

(01:07:53):
and kind of playing around with it to see if
I can get it to work nicely with just generic
rails up with apps be mine stuff. But yeah, I
think it's a very underrated gem and they I highly
recommend checking it out. So yeah, those are my three
picks for today.

Speaker 1 (01:08:11):
Awesome, Valentino, what are your picks?

Speaker 5 (01:08:14):
I just got done taking this incredible Ruby AI engineering
training and planning workshop with Max Irwin and Landing Gray.

Speaker 6 (01:08:24):
I highly recommend it.

Speaker 5 (01:08:26):
We got a bunch of folks at doximity to attend
it and just like filled so many knowledge gaps and
just learned a ton and I'm looking forward to applying
just like, yeah, a massive amount of information there.

Speaker 6 (01:08:43):
So definitely check that out.

Speaker 5 (01:08:45):
I hope they continue doing it, because yeah, I was
just incredibly well put together, and I've never used Jupiter
notebooks with Ruby before, so that was very interesting and
kind of fun.

Speaker 6 (01:08:58):
Uh So uh that that on its own kind of
worth it.

Speaker 3 (01:09:04):
My My other.

Speaker 5 (01:09:05):
Pick is I I just pre ordered this giant three
D printer from elagu. It's uh it's called orange Storm
Giga and you can print like furniture size things with it.

Speaker 6 (01:09:20):
So I'm I'm pretty excited to Uh.

Speaker 1 (01:09:23):
You meant giant.

Speaker 6 (01:09:24):
Wow, I went giant is massive. Yeah, it's the size
of a person. Uh. And it's honestly not that expensive
for what it is.

Speaker 5 (01:09:36):
Uh And so uh I recommend at least looking at it.
It's pretty pretty incredible what you can do these days.

Speaker 1 (01:09:47):
Nice your friends come over and ask you what you
do in your phone booth. All right, I've got a
few picks here, so I always do a boarding and
pick first. And so the game I'm gonna pick this
time is Machi Koro two. I have picked Machi Koro

(01:10:10):
in the past. Machi Koro two is you basically played
by the same rules as Machi Koro. The difference is
is that you have instead of the different kinds of
buildings just being all in their stacks and you can
just buy whatever's out there, you actually flip cards to

(01:10:31):
expose the different types of the different buildings. And so,
just to give a quick rundown on how the game works,
you buy buildings, you roll the dice. If you roll at
dice on a card that you have in front of
you that's green or blue, then you get then you
get money. If anyone else has a red card with
that number on it, then you have to pay them money.

(01:10:53):
And the green cards on other people's turns you also
get paid for. So that I mean that that's more
or less it you're trying. The way you win is
you build three No, you build four landmarks in Machi Koro.
Everybody has the same landmarks in Mahi Koro two. One
of the piles that you're flipping cards out of to

(01:11:14):
expose which landmark you can build or is the landmarks,
and then the others are the different building types based
on costs or based on the number year role. So
one through six and then seven through twelve. I mean
that's it. You just go until somebody's built three landmarks
in this game and you're done. And it takes forty

(01:11:38):
five minutes maybe to play a full game. It's relatively simple.
I think it's rated ten plus, and I think the
kids younger than that, not a ton younger, but younger
than that could probably play it. My nine year old
could probably play it just fine. It let's see has
a board game weight on board game Geek of one

(01:12:01):
point four eight, So you know, Casual Gamer a little
less complicated than some of the other games out there.
And yeah, I just we had a good time playing it,
so got it for Christmas. So I'm gonna pick that.
And then I've been I started the Stormlight Archive series

(01:12:25):
by Brandon Sanderson again and so I'm enjoying those, so
I'll pick those, and I'm trying to grab a link
for those. I think that's basically all I've got for
picks this time around. I started playing with open Router.

(01:12:46):
I'll guess I'll pick them too. There's a gem for that.
It's written by Obi Fernandez, and it lets you use
the different AI l ll ms and things like that
for some of the stuff you're doing. It's it's what
he recommends you use in his book about the AI development.
So anyway, check out open Router and the open Router.

(01:13:06):
Jim and Robbie, do you have some stuff you want
to shout out about?

Speaker 2 (01:13:09):
Yeah, let's see a couple of things that come to
come to mind. Is a quick shout out to Joe
Mazzati for releasing hot Wire Native this last week. It's
out on beta now, So if that's something you're interested
in him and I are going to grab coffee next week.
So we live in the same town, so we can
see each other every once in a while. That's always
fun to catch up with him. And then also i've

(01:13:31):
been real quick. We're gonna have Joe on in a
few weeks to talk about Yeah, in a few weeks
to talk about his book and the stuff he did wonderful. Also,
I've been a one of the things you mentioned talking
about Oma Zeshell. Wild thing about being part of that
CLI environment is that I get approached by a lot

(01:13:51):
of people that are building new terminal emulators all the time, like,
so usually get to be get early access to tools
and get to be early testers for things. So I've
been using a thing called Ghosty for I don't know,
maybe nine months off and on, and so that got
released a couple of weeks ago, and that's why I
was released by Mitchell Hashimoto. And it's pretty slick, and

(01:14:12):
I think there's gonna be a lot of fun innovation
on the our criminal emulators in the next few years,
so that'll be kind of exciting non tech related stuff
I'm trying to think of. It's like coming out of
the holiday season, but I recently watched the Penguin series
on HBO Max. I am not a comic, but personally
I don't go on my way. I watched like the

(01:14:32):
Batman movies every once and a while and stuff like that,
but I wasn't sure if I'd liked this type of thing.

Speaker 3 (01:14:37):
I loved it.

Speaker 2 (01:14:39):
It was such a good I really really enjoyed that
that series. And yeah, I would just say that that
was good. And then also one of my favorite bands,
Magwife from Scotland has a couple of new singles out
and a new album coming out and they're a huge
influence on my band and my my own music. Its influence,
so check out the I had another new song called

(01:15:01):
I think it was called Fanzine Made of Flesh or
something as the name of the new song that came
out this last week. That that's pretty good. So I'm
pretty pretty excited to get to see them and again
when they come on tour soon.

Speaker 3 (01:15:12):
So there's those are my picks, all right?

Speaker 1 (01:15:16):
Good deal? Well, thanks for coming. This was fascinating conversation
and it's always good to catch up.

Speaker 2 (01:15:22):
Yeah. Likewise, nice to meet too, Valentino. I uish and
thanks for having me and talk to you again some
about the point in the future. I hope

All Episodes

Rails Developers Survey: Continuous Deployment Trends and Emerging Tools - RUBY 670

Episode Transcript

Popular Podcasts

Stuff You Should Know

My Favorite Murder with Karen Kilgariff and Georgia Hardstark

The Joe Rogan Experience

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Rails Developers Survey: Continuous Deployment Trends and Emerging Tools - RUBY 670