(electronic music)
(train whistles)
- Ugh, RSpec.
All right, so, when you walked in you saw this,
that's me, that's Justin Searls,
but you can see how it's written by hand on an index card.
There's a story behind that,
this is not my talk.
Which is part of why I'm so nervous,
but really, please don't leave,
you're in the right place at least.
So you just stay where you are
and I'm gonna do my best despite this.
This is actually (yells)
not acceptable.
I'm being trolled so hard.
Okay so, this is not a bait-and-switch.
Most, I've spoken at RailsConf two times before,
and I intentionally wrote abstracts to get in
through the CFP and then I talked about
what I wanted to talk about.
So, this is not a bait-and-switch like those two.
It wasn't intentionally that, it is now.
This was supposed to be Sam Phippen's talk,
everyone go follow Sam, he's great.
Sadly, Sam is in the hospital,
so he wasn't able to give this talk,
and that's why I'm here instead.
But it's a British hospital, so he's just in hospital.
(audience laughs)
So send your good wishes to Sam.
Why me, why am I here?
Well, Sam likes to give conference presentations
wearing my company's branded t shirt, Test Double,
so people are often mistaking him
for one of our employees such that
he actually now has intro slides like,
I do not work for Test Double.
(audience laughs)
But I love them and also Searls,
which I heartily appreciate,
we love you too, Sam.
That's why we're here,
you're a great member of the community.
So this talk is going to be Phipp'n great.
(audience laughs)
Only problem is I finally understand imposter syndrome.
So, I've got a little bit of imposter syndrome
because I am a literal imposter today,
in three main categories.
One, I am not British.
And as we all know, as Americans, of those us in the room
who are American, everything out of British people's mouths
sounds a lot more intelligent, so I have that shortcoming.
And therefore today I resolve to use fewer contractions,
to speak with authority,
and to drop the rhotic R.
So let's practice this sentence together:
minitest is not betta' than RSpec.
(audience laughs)
All right, I feel better already.
Two, I lack Sam's glorious mane,
I don't have a big bushy beard.
Sam, of course, derives his RSpec powers from his beard.
This is obvious because why else would he have it?
So I have not shaved since I agreed to do this
at 7am Friday morning.
Some scraggles.
So I now know a few things,
based on the RSpec beard powers.
One, beards are itchy.
Two, RSpec.
(laughs and applause)
And three, what beard oil is.
So, if anyone, I forgot my razor, true story,
if anyone has some beard oil on them,
hook a brother up.
Third way in which I am an imposter today,
I am not on rspec-core.
Here is a little like, organizational chart of where
I fit into RSpec, that's rspec-core, and that's me
not being in it.
But you know what, apparently it's just not
a RailsConf without a talk from an RSpec committer
about RSpec.
So far, to date, the only RSpec thing
I've committed to is this talk.
So I just decided to become an RSpec committer,
right, it sounds like a good idea.
So, let's get started.
I'm gonna make my first RSpec commit, right here.
(audience laughs)
I am so committed right now to RSpec.
All right, so I'm just gonna push it up, access denied.
So I tried everything earlier in the hotel.
(audience laughs)
So let's try one more time, always works.
(audience laughs)
You know what, you get this error message
also when GitHub's down, so it's probably just that
GitHub's down.
So as this talk's resident RSpec committer,
I have some startling announcements to make.
I'm here ready to announce
the future of RSpec for you today.
Current version of RSpec is 3.4.0,
I'm here to announce the next major release of RSpec,
RSpec five.
RSpec 5 is gonna be revolutionary
because we have some really awesome headline features
that are very convenient to me and my purposes.
The first, TurboSpec.
(audience laughs)
Let me tell you about TurboSpec.
(audience laughs)
Yup.
TurboSpec dumps the ObjectSpace into the cache,
into memory, after running every single one
of your before hooks.
It does this so that it can cache
each nested example group's setup code
so that you don't have to run it across all your tests.
And then if you run the RSpec CLI
with tack, tack, turbo button, it speeds up your testa.
TurboSpec is gonna make all of our
slow RSpec suites way faster.
Warning, it doesn't work if your application
has side effects.
(audience laughs)
But for the rest of us it's gonna be just awesome.
I've another feature for RSpec 5 that I think
is gonna really just make true believers of RSpec happy.
Spec Specs.
(audience laughs)
You just create a spec of type spec,
and then you can say things like,
hey this model order I expect it to have five specs.
(audience laughs and applause)
I expect order to finish within about two hours,
to have 95% code coverage,
to limit the nesting indentation to just three contexts,
to usually pass,
(audience laughs)
and to be good code.
I don't know why they didn't have this in RSpec 3,
it's in RSpec 5.
Remember, it's important to spec spec
your spec specs, people.
Let's not get lazy.
Obama's saying things.
Audio doesn't work anymore because of their shenanigans.
Let's try one more time.
All right, what he said was, "Justin just give it a rest."
Damn it.
(audience laughs)
I'm gonna be, now I'm not gonna sleep tonight.
So, thanks audio.
All right, so I'm still, anyway, regardless,
I'm not sure if I'm cured or if I'm still impostering.
You know, I am not Sam.
If you don't know me, this is what I look like on Twitter
when I'm getting retweeted for saying terrible things.
That's me, Searls, I'd love if you became my twitter friends
and got me some feedback about how things are going.
I know it's not great so far.
This is the Justin Searl's marriage simulator,
basically it's just you sitting across a table
with me looking at my phone and making slanted faces.
(audience laughs)
So we can all emphasize with Becky Joy a little better.
And this is me on brand, I help run a software agency
called Test Double, our mission is audacious.
We're just trying to make the world's software less awful.
And I'd love if you got us any feedback,
hello@testdouble.com.
All right so, again, talk title, back to basics.
Rspec, Rails 5, what's there to know?
By the way, side bar,
did you know Sam rejected my RailsConf talk?
I just thought I should mention that,
because I am supposedly honor-bound
to cover all of this Rails 5 stuff.
Because it's important to cover
for the purpose of the program,
which I took with just nothing but grace.
So Rails 5 stuff.
My first question to Sam via text message
on Friday morning was will RSpec just work with Rails 5?
No.
(audience laughs)
and he was saying it as an implementer, right,
he's thinking about all the work that they needed to do.
Because obviously if you've ever maintained
a gem, newsflash, major Rails releases break gems
in surprising and myriad ways.
I went and searched for just open GitHub issues
that are demanding Rails 5 support.
Just search for it, and you get a whole lot of
salty randos saying hey, Rails 5 is not supported.
No description.
Give me Rails 5, you owe me, come on,
gems, work, work, give me.
Rails 5 is not even out yet, people.
(audience laughs)
So if you know a maintainer go give them, maintainer a hug
because, seriously, Rails major release upgrades
are big work.
RSpec considers this to be feature work.
They don't wanna break, make any breaking changes,
they want you to be able to upgrade very gracefully,
that's why they respect semver as much as I don't.
They're at 3.4.0, it's gonna be 3.5.0,
which means that they have to keep it running
for older version of Rails, but also new versions of Rails.
So I hope that you like, take a moment,
to thank the RSpec team for their thankless work
because everything that they're doing here
is behind the scenes.
But there is one change that we all have to know about,
which is, is it true that like, functional tests
and controller specs are really deprecated?
Well, yes, it actually is true.
They're going away with Rails 5,
they're deprecated, at least soft deprecated.
To which I say finally.
If you don't write controller specs by the way
feel free to just play with your phone
for this portion of the talk.
If you do, it all started when DHH opened
this issue saying, you know,
the mechanism for us making, verifying that you
assigned a particular instance variable
and a controller, making sure that a particular
template was going to get rendered,
those are testing implementation,
those aren't really valuable.
Let's deprecate functional tests.
And I feel like he was absolutely right.
That was a really good point.
And, of course, if you disagree you might disagree
just because you write controller specs,
but here's my beef with controller specs.
This is the testing pyramid here.
At the top of the testing pyramid
it's just a way to illustrate user full-stack tests
that call through everything in reality,
and stuff at the bottom, these are just unit tests.
Stuff in the middle are difficult to explain tests.
And that's what controller specs are.
So, the problem, right...
The opportunity.
Oh my gosh.
(audience laughs)
All right.
I'm so glad to be at one of those like,
just chill, go with the flow kind of guys.
All right, so.
The problem with controller specs at this level is that
above that point in the pyramid,
there are untestable things that can break.
And so they are only of limited value.
And everything below it, the messages that you get
are gonna be unclear reasons why things are gonna fail,
because it might be something way, way deep below you
that is actually the root cause of the failure
and the error messages aren't gonna be very helpful.
So it helps you in that very skinny way,
but I don't know how much value that really adds.
Another thing about controller specs that sucks
is that they were a lie to begin with.
Their API implies that a request is being made.
So if you've got a controller,
you do like, get index, like you're actually
making an HTTP request, and then you have these
assertions like you render this template,
or you redirect it,
or you have this http status.
Oh look, I'm making a request!
Wrong, it's just like, that's just really silly
sugar of a façade and it's just invoking
you controller methods.
Which means all this other stuff is not happening,
like middleware is not getting invoked.
So your controller specs might be passing,
when your controller is totally busted.
But they're faster!
And that's why they exist.
And they might be faster at run-time
but in my experience they're much slower at fix-time,
they're just a maintenance nightmare,
for all of that no value that they provide.
So, but, you know, despite the criticisms
controller specs, semver right, so RSpec is promising
not to break our tests with Rails 5.
The way that we are doing that,
the way that you do that, all that you have to do
is add this gem to your gem file
called rails-controller-testing,
which will reintroduce the functional testing bits
that RSpec Rails needs.
And then meanwhile the RSpec team is doing the
hard work to make it seamless.
It's my understanding,
Sam Phippen's doing a lot of that work.
And I hope that's not what put him in a hospital.
So thanks to Sam and the RSpec core team.
If you already have a lot of controller specs
stop writing those now.
There's stuff that you can do
instead of controller specs in the future.
Here are some alternatives.
One, you could write full-stack feature tests
that test that everything's fully working
when everything's really integrated.
You could also do nothing.
I do nothing, I have not written a controller spec
for seven years.
And you could also do request specs,
which are very similar, we'll talk about those in a second.
Because request specs are like honest versions
of controller specs.
They map to many tests, integration tests in Rails.
And the reason that they're honest is that,
the API looks the same, and the assertions look the same,
except it actually exercises the routing,
the middlewares, and the views,
so if something blows up, you know it's a good blow up.
Another cool thing is because it's using rack test,
you have access to the response body
and you can make assertions on the actual response
that's generated instead of all this
weird implementation stuff.
When to use request specs instead of controller specs,
or nothing.
Specs that asset like a complete API response
like if you've got like a json API
and you can assert everything that it does,
cool, request specs are probably
the right layer to test that.
Specs that just assert your assigning certain ivars
or rendering certain template, eh,
it's needlessly coupled to the implementation,
probably don't need a request spec.
Specs that assert HTML that comes out of the response body,
probably not a good idea unless
your app has absolutely no JavaScript.
Which is probably unlikely.
So that's a bit about request specs, controller specs.
Third bit.
It was in the abstract, right, that we're gonna
learn how to test ActionCable.
So does RSpec help us test ActionCable?
No.
Turns out that ActionCable testing
isn't built into Rails yet, there's an open core request,
and I assume that when that ships
RSpec will have a wrapper for it or something.
So just test through the browser for now
and make sure your website works.
All right, there you go!
You are now ready to RSpec with Rails 5.
Thanks very much, Sam, for trusting me with your talk,
there's nothing more for you to see here,
you can close Skype, Sarah, there's nothing
I think he's actually like, maybe here,
I think I see him waving actually.
Hi Sam!
Yeah, he looks excited.
Yup, all right, bye Sam!
(audience laughs)
So one time, Aaron Patterson's up in the front row,
one time I texted Aaron something and he tweeted it
and got a million retweets,
and I felt really salty about that
cuz I was like, no that way my random Internet meme
that I copied and pasted.
And he sent me this in response.
(audience laughs)
It's that fundamental attribution error.
It's Internet attribution error.
So this is my talk.
(audience laughs)
RSpec and Rails 5.
Why are you here?
Really, like, shout it out, somebody tell me.
Why you're here.
- Searls.
- No.
Next question, somebody, so why'd you come to this talk
especially if you didn't know who I was?
Okay, something RSpec related, anyone?
What's that?
(audience speaking)
Okay, thanks.
All right, thank you.
(audience speaking)
ActionCable, thank you!
RSpec cable.
Well I had two theories, cuz I couldn't
make the slides after asking you.
One, how the hell do I test ActionCable?
(audience laughs)
Sorry, for those people, cuz I don't know.
Two, I'm not happy with my test suite.
And now I have a third theory too, like, you know,
I'm new here and what the hell is all this about
because it's just like a lot of forensics
and who are these people?
I'll focus on the one that I can actually address,
which is what happens when we're still not happy
with our test suites?
Well, if you have this motivation
and that's part of why you came to this talk
maybe you were thinking like,
well RSpec might have a new feature
that'll help me hate my tests less?
Or maybe Rails has some new thing,
or removes a new thing, that will help
make the pain stop, make my test suite more sane?
I think that's a natural thing to do,
especially when you're in a conference,
we're here to learn about technology.
We're searching for tools.
And tools are easy, cuz we can grab them
off a shelf and use them,
but they're way easier than like,
critical introspection, asking ourselves hard questions like
maybe it's our fault that we have terrible tests?
There's two keys to happiness
with testing or anything in software.
One, the tools that we use.
Two, how we use those tools.
And it's not a two-step recipe.
There's a, it's like a, not a false,
it is a false dichotomy to like,
blame one side or the other.
Some people say like, oh well, clearly we just need
better tools, whenever we have a problem.
And some people have a disposition that says,
well no we just have to think differently.
We have to design harder.
Like if, the tool's failing us
we're not using it hard enough.
And that's not a good mental model either.
I like to think of it as like,
first there are people thinking,
and they were doing stuff and then they wrote tools
to help them do their job, and then the tools
our actual usage of them informs how we think about
the problem and it's this hopefully virtuous cycle,
this feedback loop.
So I do believe that tools matter, tools aren't everything.
But tools are important, and we're gonna talk about
how tools prompt behavior.
Some tools guide us in a healthy direction
to build good stuff.
Some tools enable our bad habits.
And some tools just are written to be
relatively low opinion, not very opinionated.
First I wanna talk about a tool that
enables a lot of bad habits.
It's a, you may have heard of it,
it's called rspec-rails,
and I feel like whoever invented rspec-rails was like,
here's our marching orders, we're gonna just
do whatever Rails does and then
wrap it with our CLI and DSL.
As uncritically as possible.
So, you got controllers?
Yeah, we can spec 'em.
Great.
Without thinking whether that was a good idea.
You got a testing pyramid?
We got a testing pyramid!
(audience laughs)
You want model specs, and controller specs,
and helper specs, and view specs, and routing specs,
and request specs, sure, and have feature tests too.
Just why not have all these layers?
And honestly as somebody who's,
especially when I was a novice coming in,
I was like, well clearly,
our tools are built for good reason,
they have a good reason for having all these
different tests.
Tests all of the fucking time, that's great, okay.
So I thought like, I looked at that and I was like,
man I got my work cut out for me to like,
live up to this seven layer nacho of testing.
And what I came to realize over through a lot of usage
is like, well, all those tests are very integrated.
Every single one of them will call through
to the database.
And additionally they're very redundant.
When I have a new model that I'm writing here,
and I make a change there, I have this incidental coverage
in all the tests above it,
so all those tests need to be updated as well.
And it creates a lot of like, low value work
just cleaning up all my tests.
So here's protip, here's how I use rspec-rails,
this is a secret.
My secret to using rspec-rails,
is I have this whole thing and then I blow away
all of them, except for sometimes feature specs
and sometimes model specs.
And then if I have any sort of Ruby that's like,
at all interesting, I'll write it in Ruby code.
And then I'll test it with plain old RSpec.
And that's the only way I've been able
to find sanity with rspec-rails.
But it's not the tool's fault per say,
but I had to fight that tool to get to this point.
I had to fight all the documentation,
and all the blog posts, and all of the arguments
with people about why I was having problems.
And that was not an example of a great tool experience.
Let me tell you about an experience
with a tool that I thought was really, really helpful
and great, it's name is RSpec.
RSpec itself is actually really awesome,
but I think that a lot of people have
a hard time with rspec-rails, and then they turn around
and they blame RSpec too, and I think that's
kind of unfair, it's worth it to like,
look at them separately.
So let's talk about what RSpec kinda cool.
First of all, I don't believe that RSpec
is a test framework, per say.
I think it's better to think of RSpec
as a framework for helping you to write better tests.
(audience laughs)
RSpec influences our design.
It was designed to do that.
You know, it was a response to x unit,
with lots of repetitive methods that were all
set up, like tons of tests,
set up, and action, and assert.
But what was cool about nested example groups is,
we can see the same symmetry like,
and have very terse tests that aren't redundant.
But we don't lose any clarity through
drying it up, that's one, my favorite thing about
RSpec style testing.
Additionally I love that the assertions guide,
the naming for our methods.
If I write this test and the thing doesn't exist yet,
by using this match or be silent,
it's going to assume that there is an instance method
called silent, question mark, on that class.
Which is a really handy way to like,
inform that the usage is like, sensible, like,
that's a natural name now.
Additionally, years ago, when I learned about let,
I was pairing with Corey Haines.
Corey is a really smart developer,
I really looked up to him and he's like,
let is great because it lets you call out
your setup stuff, create a new user,
and assign it to this method,
and even better, it's lazy, lazily evaluated.
And I was like, I don't know Corey, I worship you,
so lazily evaluated sounds sweet,
that's great, I'm gonna use let for everything.
So I've used let a lot.
And then another feature, let bang,
which will eagerly invoke that block,
it has this interesting thing because like,
people generally find let bang by being like,
well I want this to run in exactly this order.
I wanna make sure that it invokes.
And so Jim Weirich and I paired,
and he looked at my code base and he's like,
dude, dude, you're doing this totally wrong,
don't just use let bang for absolutely everything.
It's like, there to draw out your attention
to side effects in your code.
It should be minimal, you should have them
very, very sparingly like,
if you need to have a side effect
in order for your code to work,
that means that you have this coupling of state
not just to the arguments, but to other stuff
happening in the system.
So like, that's why there's a bang,
it means don't do it.
So, that was an interesting conversation
that I never would have had if it wasn't for RSpec.
Additionally RSpec reduces friction.
The CLI is great because it's really
you know, convenient, easy to use, pretty obvious,
helps you focus on just what you wanna run,
has a good output, and that's all work
that I'd have to do if I was building my own
rake tasks and my own sort of like,
testing CLI stuff on every project.
And I love RSpec's built-in reporters.
Oh my god we're at thirty minutes
because of all the AV stuff.
Please don't leave.
All the reporters you need,
so that you have all the CI stuff that you need,
there's so many RSpec plugins,
I love that, I'm get to focus on just my tests,
and not the stuff around my tests.
Additionally RSpec fosters empathy.
The API is designed to like,
let you have a place to write in
what the heck you're doing,
describe, you know, the slide,
and how it compliments RSpec.
You have this opportunity in there
to tell a little bit of your story in a way
that's congruent with your tests.
Another thing I love is that it shifts your perspective.
So RSpec has a domain specific language,
it does not look like normal Ruby,
and that is a level of indirection.
However, it forces me to think of my methods
not just as methods, but like, outside-in,
what's it like to use them?
What's it like from the perspective of a stakeholder?
What's it like under a different context?
I really like the DSL for forcing me out of
just thinking of just methods and classes.
Another tool, talking about tools prompting behavior,
it's possible to write that just don't have
a whole lot of opinions.
Minitest is a good example of one such tool.
And it has a different priority than RSpec,
an analogy I picked up from Aaron this week
is you can think of minitest as a race car,
it's why DHH uses minitest by the way if you don't know.
So it's lean, mean, it's essential,
it's only what you need to get your tests written.
It's all pure Ruby.
Except it has these hard bucket seats.
Versus RSpec, a luxury sedan,
with a lot of knobs and dials
but it's mostly full-featured and
quite comfortable to ride in.
So, if you want, you know, a comfortable seat,
RSpec offers you this rich, Corinthian leather experience
that you can just sit in and feel comfortable.
The zeitgeist right now,
and by the way if you don't know the word zeitgeist,
it's a German word for time snapchat.
(audience laughs)
The zeitgeist right now is saying that
minitest is really hot.
Like when I talk to all my friends
a lot of them has dropped RSpec and started using minitest.
I think it's just like, really popular right now
and I think that one of the reasons is like,
people generally spread fear and uncertainty
and doubt about RSpec, that it's too verbose,
it's bloated, it's slow, it's too much indirection,
it's better just to write pure Ruby.
You ain't gonna need it.
I'm here too, I use minitest on a lot of my projects,
I like minitest just fine.
I like that it doesn't have very many opinions
and it gets out of my way and I can just write
just the tests I want.
But of course, I carry with me the fact that
I actually have very finally, after years and years,
I have my own testing opinions that I know
work very well for me, and I can write tests
without getting myself into too much trouble, usually.
But if you're not a testing expert,
and you don't wanna be a testing expert,
or if you're on a team with novices,
what I would suggest is like,
remember I learned a lot discussing RSpec
and grappling with its API and its features
with past teammates.
And I think that you might benefit from that too
if you haven't had that experience yet.
So yeah, on one hand RSpec takes longer to learn.
But when you learn how to use RSpec
you're also learning stuff about design and testing,
and so maybe that's not so much a bug
as a feature in some cases.
So if you're still not happy with your test suites,
I suspect that you might be looking for a tool
to solve all of your problems when instead
we can use our brains and use thinking instead,
and change our approach.
Oddly enough, at RubyConf last year,
I gave a talk on exactly that,
you can find it called, is.gd/stophate.
It's called How to Stop Hating Your Tests.
And it's not about tools, it's just about thinking.
All right so, in the time remaining
I'm gonna get a little bit more meta.
Why are we here, really?
The fact that anyone came to this talk worries me.
(audience laughs)
I would have not have come to this talk.
Let me explain, let me back up.
First of all, giving somebody else's talk
is a lot like testing their code.
Cuz I've had to like, open up all of Sam's work
and his notes and stuff and try to understand
what he was gonna say here today.
So, if you see something confusing,
when you're looking at somebody else's code
and you're trying to write tests for it,
or trying to review it,
it's easy to think they are obviously a moron.
So it's important to assume that the author is smart,
and intelligent, and had reasons.
Meanwhile if you see something that's
obviously awesome, great.
It's still your job to put on a critical hat
and investigate it anyway and ask the hard questions
about why we're here.
So let's critique this talk.
Not the stuff that I said, just the Sam stuff.
Stuff I said, is fine.
(audience laughs)
This is the abstract, I assume you've read it,
I won't reread it or anything.
This is his abstract, this is the first thing I read
when he texted me to see if I could give this talk.
This is my opinion of the abstract.
People like peanut butter, people like chocolate,
slam 'em together, rspec-rails.
This talk I felt like I read the abstract, I'm like,
this could be a six paragraph blog post.
And so the next thing I did was I googled
rspec-rails 5, and found Sam's six paragraph blog post.
(audience laughs)
Yeah I was just thinking, I was mad, I was like,
why was this talk selected here?
How did this talk fly through the CFP process
without any criticality whatsoever?
Like, that just doesn't seem right.
Now granted, my talk was rejected,
and I'm a little bit biased, I might be a little salty.
But when I thought about it, I think that the reason was
that this was a safe talk.
This is a comfortable talk.
This is well within everyone here's comfort zones.
I use RSpec, I use Rails, let's find out what's new.
Great.
But I feel like that comfort should scare us,
because when we're in a group like this
that's maturing, we're getting up to
major version numbers like five, you know,
comfort can breed complacency.
So RSpec, if we're just content with where things are
and we're pretty happy with RSpec and we're just happy
to see, you know like, little tiny tweaks here and there,
make sure it continues to support stuff in the future,
you're not writing blog posts about this new RSpec thing,
you're not writing new tools.
You're talking about RSpec less.
Even if RSpec does everything you want it to do.
Minitest meanwhile lately, I've like, zeitgeist,
I've seen a lot of people talking up minitest,
writing more plugins, educating people
a bit more with blog posts.
And as a result it's getting a little bit more attention.
So it's, new person walks into the room,
they're gonna see people talking about minitest
more than RSpec, they're gonna tend to go towards minitest.
Not RSpec.
So, this reminds me a little bit of a similar dichotomy.
Rails, Rails is pretty mature now, it's over ten years old,
it solves the problems that it solves really well,
and it's pretty well know what it's good at
and what it's not.
So people talk about Rails a little bit less.
Especially all of us busy getting stuff done
and building things, we're not out there
advocating Rails anymore because we get to use
Rails at work, which is itself fantastic.
However when you look at jobs,
Rails jobs are on the decline.
They're not just slowing down, it's negative growth.
There's this other thing,
the technology that shall not be named.
(audience laughs)
Everyone's talking about node js.
Like it or not, 900% year over year
growth in jobs on indeed.
There's a lot of activity there,
and it's not about, this is not a contest
of who's the better technology,
or who solves stuff better.
It's what's the front page of Hacker News?
So my challenge is, thinking about this talk
and why the hell we're giving this talk and why we're here.
(audience laughs)
That was ironic.
(audience laughs)
Cuz that's one of our options.
The other option, if we're not willing to be uncomfortable
is we're gonna see Ruby jobs start to dry up.
And there might be, you know, fewer people
at RailsConf 2018 than this year.
Another way to think about this,
is if you're not familiar, Ruby Together
is a non-profit that pays people
to work on Ruby open-source.
Another way to think about this is ask,
what were the conditions necessary in order
for Ruby Together to seem like a necessary
and good idea?
Well, when an ecosystem is popular,
everything is easy, cuz there's just, you know,
wave after wave of person on the Internet
who's gonna write open-source for free,
just for the ego, just for the fame,
to be attributed to the new, popular thing.
Also easy, sponsored stuff.
Like Oracle backs Java.
Java's not gonna go anywhere because
Oracle's incentivized for Java to be successful.
Google is not gonna drop Go, unless they feel like it.
(audience laughs)
I already dropped the mic, but...
Javascript can not die.
Because multiple vendors have
staked their businesses on it.
Every single browser, lots, Javascript is not gonna go
anywhere, so it's a pretty safe bet.
We talk about RSpec, it's mature.
At this point.
And I don't mean mature as like a four-letter word,
mature means mostly done.
Bundler is mature.
Rails is mature, Ruby is mature,
they mostly do what they need to do
to do their job well.
But it means, as a result, that when you maintain
a popular gem like RSpec, it no longer makes you
rich and famous necessarily.
And the ecosystem, the stuff that they had to do
just to make RSpec continue working with Rails 5,
is almost all stuff that you don't actually see.
It's all internal, it's legacy code refactoring.
No one really wants to do that.
And so the reason Ruby Together needs to exist
is because the energy and the funding to keep Ruby
competitive, isn't there otherwise.
And that is disconcerting.
Cuz Ruby Together isn't gonna ever be big enough
to solve that fundamental systemic problem.
So let's talk about my real job, sales,
I spend a lot of time talking to business people
about software solutions and
building software apps and stuff.
And entrepreneurs that I've talked to
are always talking about certain technologies
that they hear about that are advised to them like,
the mean stack, like Mongo, Express, Angular,
and by the way, when people like, I've talked to
multiple business people this year who are like,
yeah well we're gonna build a new application,
we're gonna do it all in Angular one dot x.
Like, people are teaching business people,
oh you don't want Angular two, just stay on one forever.
Like, I don't get it.
We're just gonna wait, wait it out.
And Node js, the so-called mean stack.
A lot of entrepreneurs are pushing this kind of stuff.
Another one, lotta people are just assuming
based on trendiness, Node and React are just the way to go.
You know who's talking about Ruby and Rails nowadays?
Out in the marketplace?
Like, has the ear of CTOs and directors in engineering?
People spreading fear, uncertainty, and doubt
because they have their preferred upstart technology
that's faster or whatever.
And what those businesses are hearing,
is that there aren't enough Rubyists out there.
That the Rubyists that do exist cost too much.
That Ruby is slow.
And that RSpec doesn't scale.
Either at runtime or operationally.
Now if you're in the room you're like,
no, no, no, Ruby's fine, this is okay.
But I think that this is like a, real important
bit of anec-data from the life of Justin Searls
we all need to deal with to help solve
my consulting sales problem, so.
(audience laughs)
Cuz I don't like sales.
But that's why it's so frustrating,
is Rails is still the best choice
for entire classes of applications.
But because we stopped saying it a few years ago
businesses stopped hearing it.
People only share new stuff,
that excites them, that's novel.
If you were to discover immortality today,
it would drop off the front page of Hacker News
after a week or two.
People wouldn't be talking about it,
they'd find some new shiny thing,
they'd be talking about React Native 1.0.
(audience laughs)
And not that you just, you know, defeated death.
Even though that thing is way more objectively better,
it's not novel after a certain bit of time.
So the dilemma, right?
Ruby is no longer new, Ruby is still good.
We gotta do something so Ruby can remain relevant
and we can keep working on Ruby at work.
What's the we do something part?
Remember, Ruby's mature.
It does its job mostly well,
and one thing that I think our community,
that technologists need to get comfortable with,
is that it is okay for tools to be mostly finished.
It is okay for software to just mostly do its job,
and be good at what it does.
In any other industry it would be ridiculous for us
to say otherwise.
That like, oh well, that's clearly obsolete now,
because it's not, you know, super active
and they're not adding new features.
At a certain point it just does what it needs to do.
Remember I said that the keys to happiness
were our tools, we all like Ruby, we like Rails,
that's why you're here,
And how we use them.
So maybe it's time for us as a community
to deemphasize the tools,
and start talking more about how we use those tools
to accomplish really cool stuff.
Cuz there's all these evergreen problems in software.
There's all these problems that we're never gonna solve.
We're never gonna solve testing.
We're gonna just get asymtotically better each time.
We're never gonna solve design,
because we're always gonna find new ways to design code.
And human issues are never gonna be solved either.
Right?
How our code communicates its intent
to its reader is never gonna be solved.
(audience laughs)
I swear, I get like five bonus minutes.
Sarah, can I have, a minute?
She's nodding, very tepidly.
(audience laughs)
So we gotta tell stories,
that help people solve problems,
in ways that are more than just
look at this new shiny bauble.
And if you love Ruby, tell your story in Ruby,
and associate it back with Ruby.
So that Ruby remains known as a community of people
who really get object-oriented design right.
Who get testing right.
Who get community and inclusiveness right.
Being known for those things
and having people talk about those things
are enough to keep us relevant.
And when you think about who's job this is,
remember that most of the people
who made Ruby so famous in the first place
don't write Ruby anymore.
Their chapter is complete.
Most of them have moved on to other ecosystems.
Some of them are no longer even with us.
And that means that keeping Ruby relevant
is not somebody else's job.
I hate to break it to you, but the fact that you
show up to a conference called RailsConf,
in a room that holds just a couple hundred people,
means that you're one of the top couple hundred people
who's job this is now.
To keep Ruby relevant, if you care.
So, my message is make Ruby great again.
(audience laughs and applause)
#MakeRubyGreatAgain.
(audience laughs)
And tell your story, we don't have the time
to talk about it today.
Use this hashtag and tell me something
that you could do to tell a story
that might change something.
That might have an impact on others,
and might convince them that Ruby is a better solution
than the technology that shall not be named,
for whatever it is that you're doing.
Again my name is Searls, I'd love to be your friend,
I'm gonna be here for the rest of the week.
If you wanna help us in our mission to fix
how the world writes software,
consider joining Test Double,
we're always hiring great developers.
If your company's looking for senior developers
and you're struggling to find people to add to your team,
our developer consultants
are great senior developers who'd love to work
on your team with you and build stuff alongside you.
If you don't want either of those things
but you want a sticker, I've got stickers too.
And most importantly, thank you all so much for your time.
I really, really appreciate it.
(applause)
(electronic music)
(train whistles)
No comments:
Post a Comment