Make Ruby great again

The video above was recorded at RailsConf 2016 on May 5, 2016.

Background

Only a few days before RailsConf, I was asked by Sam Phippen to fill in for his talk because he was sick and couldn’t travel internationally. The only catch: I would have to speak on his topic, covering the same content, and without much in the way of ready-to-use prepared content. I stared at my white board for a few hours and agreed to do it.

The title of talk, as a result, is necessarily “RSpec and Rails 5”, but don’t let its name lead you to assume the scope of the talk is so narrow. By using the upcoming, perfunctory changes to both libraries as a jumping off point, the discussion quickly broadens to how developers relate to their tools over time, essentially asking “why should RSpec continue existing in 2016?”

From there, we consider whether the maturity of its tools has lulled the Ruby and Rails community has into a state of complacency. In an industry that’s obsessed with viewing technical novelty as potential panacea to its much more complex root cause problems, we have to ask: can a programming language continue to thrive even after its tools and core libraries are mostly finished? What can the community do to foster continued growth in such an environment? Whose job will it be?

Ruby has never been a more productive environment to work in, and as a result it’s never been at greater risk of slipping into irrelevancy. These are important discussions to have as the dust continues to settle for the tools Rubyists use to do their job.

Related resources

Here are links to a some of things I referenced in the talk, in roughly the order they appear:

• RSpec
• Rails 5
• Imposter syndrome
• Beard oil
• Me on twitter
• Semantic versioning (SemVer)
• DHH’s thread on deprecating functional tests
• Controller specs
• The testing pyramid
• Request specs
• Pull request for ActionCable testing
• The “I made this” meme
• rspec-rails
• Redundant test coverage
• RSpec’s nested example groups
• RSpec’s predicate matchers
• RSpec’s let and let!
• Minitest
• Corinthian leather
• Zeitgeist
• YAGNI
• Video: How to Stop Hating Your Tests
• Sam’s abstract
• RSpec’s Rails 5 announcement
• Indeed Job Trends
• RubyTogether
• The “MEAN” stack
• React.js
• Hacker News
• #MakeRubyGreatAgain

‍

Transcript of the talk

[00:00:00] Alright 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.

‍

[00:00:17] So you just stay where you are, and I'm gonna do my best. Despite This is actually Ah! Not acceptable!

‍

[00:00:29] I am being trolled so hard. Ok 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. This is not a bait and switch like those two. It wasn't intentionally that.

‍

[00:00:44] 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. So send your good wishes to Sam. Why me? Why am I here? Sam likes to give conference presentations wearing my company's branded t shirt Test Double.

‍

[00:01:13] And 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, 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 fip and great.

‍

[00:01:34] 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 those of us in the room who are American, everything out of British people's mouths sounds a lot more intelligent.

‍

[00:01:53] So I have that shortcoming. And therefore today I resolve to use fewer contractions, to speak with authority, and to drop the erotic R. So let's practice this sentence together. Mini test is not better than R spec. Alright. I feel better already. Two, I lack Sam's glorious mane. I don't have a big bushy beard.

‍

[00:02:18] Sam, of course, derives his R Spec 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 R Spec beard powers. One, beards are itchy. Two, R Spec.

‍

[00:02:51] 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 thing, 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 in to RSpec. That's RSpec core, and that's me not being in it.

‍

[00:03:15] 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 decided to become an RSpec committer, right? Sounds like a good idea. Let's get started. I'm going to make my first RSpec commit right here.

‍

[00:03:36] I am so committed right now to RSpec. Alright, so I'm just going to push it up. Access denied. I tried everything early in the hotel. So let's try it one more time. Yeah, always works. 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.

‍

[00:04:04] 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 5. RSpec 5 is going to be revolutionary because we have some really awesome headline features that are very convenient to me and my purposes.

‍

[00:04:25] The first, TurboSpec. Let me tell you about TurboSpec.

‍

[00:04:36] Yep. Turbo spec dumps the object space 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 setup code so that you don't have to run it across all your tests. And then if you run the R spec CLI with tac turbo button, it speeds up your tests.

‍

[00:04:57] TurboSpec is going to make all of our slow RSpec suites way faster. Warning, it doesn't work if your application has side effects. But for the rest of us, it's going to be just awesome. I have another feature for RSpec 5 that I think is going to really just make True believers of RSpec happy.

‍

[00:05:16] Spec specs. You just create a spec of type spec, and then you can say things like, hey, this model order, I expect it to have 5 specs.

‍

[00:05:35] I expect order to finish within about 2 hours. To have 95 percent code coverage. To limit the nesting and indentation to just 3 contexts. To usually pass. 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 your spec specs, people.

‍

[00:05:58] Let's not get lazy. And I said, Justin, just give it a rest. Obama's saying things.

‍

[00:06:12] Audio doesn't work anymore because of their shenanigans. Let's try one more time. And I said Justin, just give it a rest. All right. What he said was Justin, just give it a rest. Damn it. I'm going to be, now I'm not going to 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.

‍

[00:06:37] 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 friend and got me some feedback about how things are going. I know it's not great so far. This is the Justin Searls marriage simulator.

‍

[00:06:55] Basically, it's just you sitting across the table with me looking at my phone and making slanted faces. So we can all empathize with Becky Joy a little better. And this is me on brand. I 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.

‍

[00:07:13] And I'd love if you got us any feedback. Hello at testdouble. com. Alright again, talk title. Back to basics. RSpec, Rails 5. Now, what's there to know? By the way, sidebar, did you know Sam rejected my RailsConf talk?

‍

[00:07:32] I just thought I should mention that, because I am supposedly honor bound to cover all this Rails 5 stuff, because it's important to cover for the purpose of the program, which I took with just nothing but grace. Rails 5 stuff. My first question to Sam via text message on Friday morning was, Will RSpec just work with Rails 5?

‍

[00:07:52] No. And he was saying it as an implementer, right? He was thinking about all the work they needed to do. Because obviously, if you've ever maintained a gem, News slash, 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.

‍

[00:08:12] 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. If you know a maintainer, go give a maintainer a hug because seriously, Rails major release upgrades are big work.

‍

[00:08:39] RSpec considers this to be feature work. They don't want to 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. 40 now, it's gonna be 3. 5. 0, which means that they have to keep it running for older versions of Rails, but also new versions of Rails.

‍

[00:08:56] So I hope that you 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 it true that functional tests and controller specs are really deprecated?

‍

[00:09:09] 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, the mechanism for making verifying that you assigned a particular instance variable in a controller, making sure that a particular template was going to get rendered.

‍

[00:09:33] Those are testing implementation, those aren't really valuable, let's deprecate functional tests. And I feel like he was absolutely right, that, 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.

‍

[00:09:48] This is the testing pyramid here. At the top of the testing pyramid, it's just a way to illustrate these are 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.

‍

[00:10:04] The problem, right? The opportunity. Oh my gosh. Alright. Alright. I'm so glad to be one of those just chill, go with the flow kind of guys. Alright, 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're only of limited value.

‍

[00:10:35] And everything below it, the messages that you get, are going to give you unclear reasons why things are going to fail, because it might be something way deep below you, that is actually the root cause of the failure, and the error messages aren't going to be very helpful. So it helps you in that very skinny way, but I don't know how much value that really adds.

‍

[00:10:50] 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 git, index, like you're actually making an HTTP request. And then you have these assertions like you rendered this template, or you redirected, or you have this HTTP status.

‍

[00:11:06] Oh look, I'm making a request. Wrong. It's just that's just really silly sugar of a facade. And it's just invoking your controller methods. Which means all this other stuff is not happening. Like middleware is not getting invoked. Your controller specs might be passing when your controller is totally busted.

‍

[00:11:22] But they're faster! And that's why they exist. And They might be faster at runtime, but in my experience they're much slower at fixed time. They're just a maintenance nightmare for all that no value that they provide. But, despite the criticism of controller specs, Semver, right? So RSpec is promising not to break our tests with Rails 5.

‍

[00:11:41] 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.

‍

[00:11:55] It's my understanding Sam Phippen's doing a lot of that work. And I hope that's not what put him in the hospital. So thanks to Sam and the RSpec core team. If you are, 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.

‍

[00:12:11] Here's 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 can also do request specs. Which are very similar.

‍

[00:12:27] We'll talk about those in a second. Because request specs are like honest versions of controller specs. They bind to, they map to minitest 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, it's a good blow up.

‍

[00:12:47] Another cool thing is because it's using RackTest, 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 assert like a complete API response, like if you've got like a JSON API, and you can assert everything that it does.

‍

[00:13:05] Cool. Request specs are probably the right layer to test at. Specs that just assert you're assigning certain IVARs or rendering certain templates, 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.

‍

[00:13:24] 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 going to learn how to test action cable. So how, does RSpec help us test action cable? No. Uh, turns out that action cable testing isn't built into Rails yet.

‍

[00:13:40] There's an open pull request. And I assume that when that chips RSpec will have a wrapper for it or something. So just test through the browser for now and make sure your website works. Alright, there we go. You're now ready to RSpec with Rails 5. Thanks very much Sam for trusting me with your talk.

‍

[00:13:57] 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 just looks excited. Yep. Alright. Bye Sam. So one time, Aaron Patterson's up in the front row. One time I I texted Aaron something and he tweeted it and got a million retweets.

‍

[00:14:19] And I felt really salty about that because I was like, no, that was my random internet meme that I copied and pasted. And he sent me this in response. It's not fundamental attribution error.

‍

[00:14:34] It's internet attribution error. This is my talk.

‍

[00:14:43] RSpec and Rails 5. Why are you here? Straight, really? Shout it out. Somebody tell me why you're here. No. Next question. Somebody, why did you come to this talk, especially if you didn't know who I was? Okay. Something RSpec related? Anyone? What's that? Okay. Thanks. All right. Thank you. Action cable. Thank you.

‍

[00:15:20] Rspec cable. I had two theories because I couldn't make the slides after asking you. One, how the hell do I test action cable? Sorry for those people because I don't know. Two, I'm not happy with my test suite. And now I have a third theory too 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.

‍

[00:15:41] 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. If you have this motivation and that's part of why you came to this talk, maybe you were thinking like our spec might have a new feature that'll help me hate my tests less.

‍

[00:15:55] 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 at a conference, we're here to learn about technology. We're searching for tools and tools are easy because 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.

‍

[00:16:19] 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 it's like a, not a false dichotomy, it is a false dichotomy to blame one side or the other. Some people will say oh clearly we just need better tools whenever we have a problem.

‍

[00:16:37] And some people have a disposition that says no, we just have to think differently. We have to design harder. 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 first there were people thinking and they were doing stuff and then that, that they wrote tools to help them do their job.

‍

[00:16:54] And then the tools are actually 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 going to talk about how tools prompt behavior. Some tools guide us in a healthy direction to build good stuff.

‍

[00:17:14] Some tools enable our bad habits and some tools just are written to be relatively low opinion, not very opinionated. First I want to talk about a tool that enables a lot of bad habits. It's you may have heard of it, it's called RSpec Rails.

‍

[00:17:33] And I feel like whoever invented RSpec Rails was like, here's our marching orders, we're going to just do whatever Rails does and then wrap it with RCLI and DSL as uncritically as possible. You got controllers? Yeah, we can spec them. Great. Without thinking whether that was a good idea. You got a testing pyramid?

‍

[00:17:50] We got a testing pyramid. 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 clearly, our tools are built for good reason.

‍

[00:18:08] They have a good reason for having all these different tests. Test all the fucking time. That's great. Okay. So I thought I looked at that and I was like, man, I got my work cut out for me to live up to this. 7 layer nacho of testing and What I came to realize over through a lot of usage is All those tests are very integrated.

‍

[00:18:25] 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 now need to be updated as well. That creates a lot of like low value work just cleaning up all my tests.

‍

[00:18:43] So here's pro tip. 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 future specs and sometimes model specs. And then if I have any sort of Ruby that's at all interesting, I'll write it in Ruby code and then I'll test it with plain old RSpec.

‍

[00:19:03] 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 se, 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.

‍

[00:19:20] Let me tell you about an experience with a tool that I thought was 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 RSpec too and I think that's unfair.

‍

[00:19:37] It's worth it to look at them separately. So let's talk about what makes RSpec cool. First of all, I don't believe that RSpec is a test framework per se. I think it's better to think of RSpec as a framework for helping you write better tests. RSpec influences our design. It was designed to do that.

‍

[00:19:55] It was a response to XUnit with lots of repetitive methods that were all set up, like tons of test set up and action and assert. But what was cool about nested sample, nested example groups is we can see the same symmetry and have very terse tests that aren't redundant but we don't lose any clarity through drawing it up.

‍

[00:20:13] 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 matcher, be silent, it's going to assume that there is an instance method called silent question mark on, on that class, which is a really handy way to inform that the usage is like sensible.

‍

[00:20:34] That's a natural name now. Additionally years ago when I learned about let, I was pairing with Corey Haynes. Corey is a really smart developer. I really looked up to him and he's let is great because it lets you call out your setup stuff, create a new user and assign it to this method.

‍

[00:20:49] 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 going to use let for everything. So I'd use let a lot. And then another feature let bang, which will eagerly invoke that lock. It, it has this interesting thing because like people generally find letbang by being like I want this to run in exactly this order.

‍

[00:21:11] I want to make sure that it invokes. And so Jim Weirich and I paired and he looked at my code base and he's dude, you're doing this totally wrong. Don't just use letbang for absolutely everything. It's like there to draw out. You should allow your attention to side effects in your code.

‍

[00:21:24] It should be minimal. You should have them very sparingly. 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. That's why there's a bang. It means don't do it.

‍

[00:21:37] So that was an interesting conversation that I never would have had if it wasn't for our specs. Additionally, RSpec reduces friction. The CLI is great because it's really convenient, easy to use, pretty obvious, helps you focus on just what you want to run, has 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.

‍

[00:21:59] And I love RSpec's built in reporters. Oh my God, we're at 30 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 get to focus on just my tests and not the stuff around my tests.

‍

[00:22:14] 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, the slide and how it complements RSpec. You have this opportunity in there to tell a little bit of your story in a way that's fun. It's congruent with your tests.

‍

[00:22:29] 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 outside in, what's it like to use them? What's it like from the perspective of a stakeholder?

‍

[00:22:46] 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 tools 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.

‍

[00:23:03] And analogy I picked up from Aaron this week is you could 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.

‍

[00:23:20] Versus R Spec, a luxury sedan with a lot of knobs and dials and, but it's mostly full featured and quite comfortable to ride in. So if you want, a comfortable seat, R Spec 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.

‍

[00:23:47] The Zeitgeist right now is saying that Minitest is really hot. Like when I talk to all my friends, a lot of them have dropped to RSpec, started using Minitest. I think it's just 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.

‍

[00:24:08] 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, 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.

‍

[00:24:32] But if you're not a testing expert, and you don't want to be a testing expert, or if you're on a team with novices What I would suggest is 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.

‍

[00:24:49] 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 your problems when instead we can use our brains and use thinking instead and change our approach.

‍

[00:25:11] Oddly enough at RubyConf last year I gave a talk on exactly that. You can find it called is. gd slash stop hate. It's called how to stop hating your tests. And it's not about tools, it's just about thinking. Alright in the time remaining, I'm going to get a little bit more meta. Why are we here, really?

‍

[00:25:32] The fact that anyone came to this talk worries me.

‍

[00:25:40] I would not have come to this talk. Let me explain. Let me back up. Giving, first of all, giving somebody else's talk is a lot like testing their code. Because I've had to like, open up all of Sam's work and his notes and stuff and try to understand what he was going to say here today. 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're obviously a moron.

‍

[00:26:06] 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.

‍

[00:26:27] The stuff I said is fine. This is the abstract. I assume you've read it. I won't re read 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.

‍

[00:26:44] People like peanut butter, people like chocolate. Slam them 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.

‍

[00:27:02] And 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 whatsoever. 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.

‍

[00:27:26] 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, it's maturing and we're getting up to major version numbers like five, comfort can breed complacency.

‍

[00:27:46] So our spec, if we're just content with where things are and we're pretty happy with our spec and we're just happy to see, like little tiny tweaks here and there and make sure it continues to support stuff in the future. You're not writing blog posts about this new R spec thing. You're not writing new tools.

‍

[00:28:01] You're talking about our spec less, even if our spec 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 little bit more with blog posts, and as a result it's getting a little bit more attention.

‍

[00:28:14] 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. This reminds me a little bit of similar dichotomy, Rails. Rails is pretty mature now, it's over 10 years old, it solves the problems that it solves really well, and it's pretty well known what it's good at and what it's not.

‍

[00:28:33] 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.

‍

[00:28:51] It's negative growth. There's this other thing, the technology that shall not be named.

‍

[00:29:00] Everyone's talking about no JS, like it or not 900 percent 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.

‍

[00:29:28] That was ironic.

‍

[00:29:35] Because 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, fewer people at RailsConf 2018 than this year. Another way to think about this is if you're not familiar, Ruby together is a nonprofit that pays people to work on Ruby open source.

‍

[00:29:57] Another way to think about this is to ask what were the conditions necessary in order for Ruby together to seem like a necessary and good idea? When an ecosystem is popular, everything's easy because there's just. Wave after wave of person on the internet who's going to write open source for free just for the ego, just for the fame to be attributed to the new popular thing.

‍

[00:30:16] Also easy, sponsored stuff. Oracle backs Java. Java's not going to go anywhere because Oracle's incentivized for Java to be successful. Google is not going to drop Go unless they feel like it.

‍

[00:30:32] I already dropped the mic, but it's JavaScript cannot die because multiple vendors have staked their businesses on it. Every single browser, lots of JavaScript is not going to go anywhere. So it's a pretty safe bet. We're talking about our spec. It's mature at this point, and I don't mean mature is like a four letter word.

‍

[00:30:56] Mature means mostly done. Bundler is mature. Rails is mature, Ruby is mature, they mostly do what they need to do their job well. But that 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.

‍

[00:31:19] It's all internals, it's legacy code refactoring. No one really wants to do that. And so the reason RubyTogether needs to exist is because the energy and the funding to keep Isn't there otherwise and that is disconcerting because Ruby together isn't going to ever be big enough to solve that fundamental systemic Problem.

‍

[00:31:38] So let's talk about my real job Sales, I spent a lot of time talking to business people about software solutions and building software apps and stuff And entrepreneurs that I talk to are always talking about certain technologies that they hear about that are advised to them. The mean stack, like Mongo, Express, Angular, and by the way, when people I've talked to multiple business people this year who are like, Yeah, we're gonna build a new application, we're gonna do it all in Angular 1.

‍

[00:32:05] x. People are teaching business people, Oh, you don't want Angular 2, just stay on 1 forever. I don't get it, I'm just gonna wait it out. And Node. js, the so called meme stack. A lot of entrepreneurs are pushing this kind of stuff. Another one, a lot of people are just assuming, based on trendiness, Node and React are just the way to go.

‍

[00:32:25] You know who's talking about Ruby and Rails nowadays, out in the marketplace? Has the ear of CTOs and Directors of 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.

‍

[00:32:43] That the Rubyists that do exist cost too much, that Ruby is slow, and that Rails doesn't scale, either at runtime or operationally. Now if you're in the room and you're like no, Ruby's fine, this is okay. But I think that this is like a real important bit of anecdota from the life of Justin Searls we all need to deal with to help solve my consulting sales problems.

‍

[00:33:05] I don't like sales. But that's why it's so frustrating, as 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.

‍

[00:33:38] People wouldn't be talking about it, they'd find some new shiny thing, they'd be talking about React Native 1. 0. And not that you just, defeated death. Even though that thing is way more objectively better, it's not novel after a certain So the dilemma, right? Ruby is no longer new. Ruby is still good.

‍

[00:33:59] 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.

‍

[00:34:22] It is okay for software to just mostly do its job and be good at what it does. I, in any other industry, it would be ridiculous for us to say otherwise oh, it's clearly obsolete now because it's not, super active and they're not adding new features. At a certain point, it just does what it needs to do.

‍

[00:34:37] Remember I said 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 de emphasize the tools and start talking more about how we use those tools to accomplish really cool stuff. Because there's all these evergreen problems in software.

‍

[00:34:56] There's all these problems we're never going to solve. We're never going to solve testing. We're going to just get asymptotically better each time. We're never going to solve design. Because we're always going to find new ways to design code. And human issues are never going to be solved either. Right?

‍

[00:35:12] How our code communicates this intent to its reader is never going to be solved.

‍

[00:35:21] I swear, I get five bonus minutes. Sarah, can I have a minute? She's nodding very tepidly.

‍

[00:35:30] So we got to tell stories that help people solve problems in ways that are more than just look at this new shiny bobble. 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, right?

‍

[00:35:48] 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 whose job this is, remember that most of the people who made Ruby so famous in the first place don't write Ruby anymore.

‍

[00:36:04] 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 whose job this is now.

‍

[00:36:26] To keep Ruby relevant, if you care. My message is make Ruby great again.

‍

[00:36:44] Hashtag, make Ruby great again.

‍

[00:36:48] 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 Ruby. Then the technology that shall not be named for whatever it is that you're doing.

‍

[00:37:08] Again, my name is Searls. I'd love to be your friend. I'm going to be here for the rest of the week. If you want to 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 is looking for senior developers and you're struggling to find people to add to your team, our developer consultants are great senior developers who would love to work on your team with you and build stuff alongside you.

‍

[00:37:28] 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 appreciate it.

‍