There's nothing new under the sun

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Justin and I were honored to co-present this presentation at Rubyconf 2017 in New Orleans. Our goal was to rediscover what drew people to Ruby in the years before we joined the community. In the talk, we shared a bunch of talks and blog posts from other Rubyists in the past, and this post shares all of those links here, in the order that they appeared, starting with Chris Wanstrath’s Ruby Hoedown 2008 Keynote

Kindness

Powerful

Productive and pragmatic

Creative

Thoughtful

Delightful

You

The cutting room floor

Here are some other links that just barely missed the cut to make the talk:

Do you know about a fantastic resource we missed? Let us know!

Transcript of talk

[00:00:00] All right this presentation is titled, There's Nothing New Under the Sun. It is the first in a track, a three part track that you're experiencing called the future of Ruby. So let's hear a little bit about Ruby's future. In the future, Ruby will become more popular. There will be more implementations, and there will be more programmers using it.

‍

[00:00:24] More machines with it installed by default. And more people writing blogs about it. There will also be more people reading blogs about it. I know this is getting crazy, but you have to trust me because I'm keynoting. So that was 2008 Ruby Hoedown. Chris Wonstrath, the CEO of GitHub, telling us a little bit about what the future would be like.

‍

[00:00:44] This presentation is the future of Ruby, part one, the past. And at the heart of all of my talks that I present to Ruby conferences, I'm asking the question, why do we choose Ruby? I feel like we need to constantly re evaluate this and justify it and come up with good answers. And to be honest, that answer has evolved over time.

‍

[00:01:04] For example, if it was before 1998, odds are you knew Japanese. If you picked up Ruby in 98, you were literally Dave Thomas. Not that Dave Thomas, mind you, for the younger people. No the one that wrote the Pragmatic Programmer with Andy Hunt. If you came in before 2005, you're probably really into extreme programming, like test driven development.

‍

[00:01:22] In 2005, it was all about Rails, as was 2008 and 2012. And if you're learning Ruby today for the first time, it's probably because that your manager was a big fan of Rails back in their day. Thank you. But that oversimplifies things a little bit, so I'll share some of my perspective. I came to Ruby first in 2005.

‍

[00:01:43] I was working through Kent Beck's Extreme Programming book, Learning Test Driven Development, and loving it. I was writing a lot of Java, or I should say I was writing a lot of XML and curly braces and not getting a lot done. I was also writing a lot of PHP and slinging thousands of lines of code that I had no hope of maintaining.

‍

[00:01:59] And I studied in Japan that year, and I genuinely my Japanese friends were really excited about the worldwide notoriety that this little programming language called Ruby was gaining. But if I ask the same thing about somebody in 2017, like, why do they choose Ruby nowadays? PHP has a perfectly suitable web framework.

‍

[00:02:14] Java does as well. Microsoft with NET has embraced open source all of a sudden, and even the Mac. To most people, if you want to teach them how to program, they're being handed Node and React by default, as opposed to Rails these days. Elixir and Elm have a lot of the mojo, the new hotness.

‍

[00:02:29] If you want to do functional, you can do back end and front end closure. PLT nerds love Rust, and some people use Go.

‍

[00:02:41] So this talk is really a retrospective. I want to talk about the things that drew people to Ruby originally, because if we rediscover that, it'll help orient us about where we want to take Ruby from here. But honestly, that sounded like a lot of work. There's over 2, 100 Ruby talks on Confreaks alone. And soon this is gonna be one of them.

‍

[00:03:00] And I, frankly, I just needed some help. So as an employer, I pulled a Mystery Science Theater 3000 move and locked one of my colleagues in a room for three months to do nothing but watch Ruby talks. His name is Josh Greenwood, and he came to Ruby a little later, in like 2012, and at that point, Rails was the default web framework choice in the industry.

‍

[00:03:20] In a lot of ways we'd reached a point of maturity with Sandy's object oriented design book getting a lot of steam and attention. That was also right after Rail shipped the Asset Pipeline, which solved the problem of JavaScript packaging once and for all. And it was also the height of the Great Coupon Wars, where everyone I knew Groupon or LivingSocial, if they didn't already work at GitHub.

‍

[00:03:44] So I'd like to welcome Josh up to the stage.

‍

[00:03:52] Thank you so much for having me. So let me tell you a little bit about my very naive plan. So I thought maybe I'd just go back and watch RubyConf videos from the first couple years of RubyConf. What Justin failed to tell me is they didn't actually start recording those until 2007. So that was a bummer.

‍

[00:04:05] So then I thought maybe I'll go check out some early versions of Ruby and see if I can get those to compile. That did not go well for me at all. So then I thought, I was getting frustrated, I thought, where does the internet store all of its most valuable knowledge? Twitter, of course. So I thought, maybe I'll go see what DHH was talking about when he first announced Rails.

‍

[00:04:22] Yeah, so you might be thinking to yourself Josh, Rails, er, Twitter was not around back then, and you would be totally right. So I was clearly missing some of the context of the things that came before me, and I suspect some of the room might be as well. So today, my goal is to share some of the blog posts, the talks, the exercises, and the conversations we had with folks in the Ruby community to try to unearth some of what drew people to Ruby in the first place.

‍

[00:04:46] Because our goal really is to reflect on these various facets of what made us all fall in love with Ruby and its community and to make it just the awesome language ecosystem that it is so that we can think hard about what we want to do to take it forward. But as a result, this talk is not an entree.

‍

[00:05:03] We're not going to be up here with some big rhetoric trying to convince you of something. Rather, these are mere appetizers showing you some of, Josh and my favorite talks and blog posts and ideas from the past. Hoping to get you to engage with those too. And please don't fret over all of the individual URLs and stuff and trying to take a picture of the screen or something.

‍

[00:05:22] We're gonna post to our blog right after the talk sources of every single thing that we reference. So just keep an eye out of that, for that later today. All right, without any further ado, let's sit back, and Josh, show me what you got. So let's start at RubyConf Orlando in 2008. Matz is speaking.

‍

[00:05:39] Why we choose Ruby? And everyone has their own independent reasons for choosing Ruby. But, for me, it's very simple. It is my beloved masterpiece. Why we choose Ruby? Just because Ruby on Rails. Could you raise your hand if you stay, if you are going to stay in Ruby on Rails and not interested in Ruby itself?

‍

[00:06:04] Why we choose Ruby? No, yeah, yes, this is Ruby conference. Yeah, love is a great the power behind Ruby. And the, and it is the very reason behind Ruby I think, I believe. I love people using Ruby. And I love people who loves Ruby. And, I love you all.

‍

[00:06:25] Matt said that this acronym embarrasses him, but Minaswan, Matt's is nice and so we are nice, was so important to the Ruby community as it became today. That, he set the tone as the language designer, you don't see very many language designers give keynotes like that, right? But that kind and welcoming spirit is one of my favorite things about Ruby.

‍

[00:06:47] Let's jump to Scotland Ruby Conf in 2011. Our friend Chad Fowler is speaking here. Who here is in the service industry? All right. Actually, you're all in the service industry, so everyone who didn't raise your hand, you're wrong. Everyone who was sitting next to them, give them a funny look. Our jobs are to be like an adventure tour guide for our customers, to take them into these scary places, allow them to feel the thrill of, whatever it happens to be that we're doing, not to treat them like idiots and make them, stay in a rubberized room so they can't mess anything up, but to allow them to get as close as they want to the edge and make it safe for them to do that.

‍

[00:07:31] Another thing that everyone else is mentioning in this conference is Corey Haynes. Here's a tweet that Corey did recently. Contemplating what practices could constitute a list of required practices of modern software development. So you're probably all thinking Unit testing, right? And source control, et cetera, et cetera, et cetera.

‍

[00:07:48] Justin Gateland says, Giving a shit. Actually really giving a shit. Knowing the first thing about coding and then giving a shit. And I thought, that is pretty deep.

‍

[00:08:02] He said a Lexus dealership was his best experience, which was not all that helpful, so I said, in what way? And he said this, the feeling that they do ten minutes of work to save you one minute of your time. And then I think the most important piece of this caring like crazy day. The goal that I have in my new job, and therefore in my new life here, is to kill cynicism wherever I can.

‍

[00:08:35] But rather than be cynical about that stuff, why don't you just fix it? Cynicism is laziness. Speaking of Dave, in the Pragmatic Programmer, Dave and Andy have, one of their little snippets, I think they call them tips, that says, always answer every email that you get. Which kind of sounds stupid.

‍

[00:08:53] Is that really a bullet? And one of the, major headings in the Pragmatic Programmer, the classic, the computer programming classic? And it is. And the funny thing is, that might be the only one I can remember having read it ten years ago. I remember thinking it was weird, though, when I first read it.

‍

[00:09:07] But it's such great advice. And when you're someone like Dave, he did answer my email, in fact, I think that's why I emailed him. Because I knew he was going to answer it.

‍

[00:09:16] We emailed Dave Thomas. We asked, what was the early Ruby community like in the West? He said, there was a mailing list, it was mostly in Japanese, but English speakers were encouraged to post too and folks would reply. Often we found ourselves communicating purely through code. Someone would post a broken test and one of the maintainers would either correct the test or correct Ruby.

‍

[00:09:38] I started by asking Matz's permission to write the book. He was enthusiastic and helped an incredible amount, answering hundreds of questions, and occasionally changing the language or libraries as I found edge cases. That book, by the way, is the Pickaxe book, and if you haven't seen it, this was an indispensable API reference and guide for anyone using Ruby through the mid aughts.

‍

[00:09:58] The book was published at the end of 99 and led to the first international Ruby conference the following year in Florida. There were 30 to 40 people there, including folks from Japan and Europe. The moral of the story is, that if you ever need help, just email Dave Thomas. And he'll reply to you. Let's jump to 2007.

‍

[00:10:15] Ryan Bates had just started producing RailsCasts. He's basically got me through my first job.

‍

[00:10:20] This is where Rails 2. 0 comes in really handy, because you get this new rake task called db create. And this will create the database for the current environment. Whoa. So a lot of fancy new additions to migrations and rails too, which will really save us a lot of time. Also this T dot timestamps here, what this will do is add a created at and updated at columns to this table, because rails assumes you pretty much always want that.

‍

[00:10:50] That's a lie. I wish that rails would just do timestamps by default. And I had to say opt out of timestamps because I always forget it for the first month. But you know what? A lot of people over the years have complained to various degree that Rails is too magic. But, if you were really in the Ruby community, in the Rails community, no you just didn't watch enough Railscasts.

‍

[00:11:09] That explained most of everything. And that complaint is valid in that, yeah, there was a ton of tribal knowledge. Ruby's dynamic, it was maybe under documented. Things were definitely moving really fast. But there was an unintended side effect of all that tribal knowledge which is that it forced us to create tribes.

‍

[00:11:28] And I don't think that we really appreciate the fact that Ruby has more local meetups and regional conferences than any other language at size. And it's because the way that the language works and how all of our libraries are constructed require us to talk to each other. And I think that's really special.

‍

[00:11:44] In fact, when I look back, there's something about Ruby and the language and the tools and the community that's just like really kind and welcoming. And it's something, it's one facet I really appreciate. In 2004, a blog post called Tour de Babel was written by Steve Yegge. And here's what he had to say about Ruby.

‍

[00:11:59] Ruby took Perl string processing and Unix integration as is, meaning the syntax is identical and so right there, before anything else happens, you already have the best of Perl. And that's a great start, especially if you don't take the rest of Perl. But then Mats took the best of Lisp processing from Lisp, the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.

‍

[00:12:22] And he somehow made it all work together so well, you don't even notice that it has all that stuff. I learned Ruby faster than any language out of 30 or 40 total. It took me about three days before I was more comfortable using Ruby than I was in Perl, after eight years of Perl hacking. One of the things I've always loved about Ruby is that it has all of these features, but constrains the developer with almost no rules as to how to use them.

‍

[00:12:48] So it is dangerous, but it also trusts the developer to express themselves. And very few other languages, even the other hip and trendy languages of our day, Check both of these boxes. I think Ruby still stands out. Next is Mountain West Ruby in 2008. Giles Boket is speaking here. And that's Zed Shah flipping off Giles.

‍

[00:13:07] One of the things that Ruby is famous for is metaprogramming. Which is programming, programming itself. But the thing is, that's not usually what we really do when we're doing metaprogramming, this magic. Because it's not metaprogramming. It's just programming. What we're really doing is meta o o.

‍

[00:13:22] What it does is if you add a method to an object, it says I'm in yourself, adding your name. Okay, I'm in your oatmeal, adding your cranberries. That's eccentric. Giles is eccentric. I just took those, I'm in your X adding your Y. I'm creating a new whatever. I took that and I just changed it to return Ruby code, right?

‍

[00:13:42] So now, instead of printing random text to the screen like a log file, what it's doing is it's creating code. Now there's no reason that you couldn't put executable code in a log file. But when you run it, you end up with Python that populates a graph drawing program for NodeBoxer. And this is what that graph looks like.

‍

[00:14:01] And obviously it is not stunning, right? It is not gorgeous. It is a simple object graph. Read this book. And I've only ever heard one other person, or read one other person, say that. The other person who said that is David Hahnemeyer Hansen. Now, the way this book starts is it starts with an EJB application, right?

‍

[00:14:20] It was 2003. You've got a legacy app. With 150 tables. You're using EJB, so you need 7 files for every table that you want to grok with your app. So that comes out, 7 times 150, that comes out to 1, 050 Java files, right? By hand, that takes a very long time to create. With generators, he created it very swiftly.

‍

[00:14:44] Everybody who talks about Rails, they're like, magic makes programmers more productive. Bullshit. Code generation makes programmers more productive. Oh, we emailed Chad Fowler too. And he's right there, and he also replied to our email. One of the kind of things that kept coming up is code generation.

‍

[00:15:04] He had this to say, and then I started doing stuff like building DSLs to generate code, in his case Java, so I could write code in Ruby and no one would have to know that it was Ruby. It's true, everyone was doing code generation in Ruby back then. And in the back of my mind, I'm just imagining how funny it is that before Rails, one of the core use cases for Ruby was to generate other programming language code so that people didn't have to know you were writing Ruby.

‍

[00:15:28] And so we've come a long way. Next up is Codemash in 2012, a talk given by Gary Bernhardt, the guy who sells screencasts at destroyallsoftware. com. And this is what his website looked like after he learned CSS. And this has got to be one of the best lightning talks ever given, at least that I watched.

‍

[00:15:48] Let's talk about Ruby. Ruby unlike some other dynamic languages does not have bare words, so you cannot just type words in and have strings come out, unless you define a particular method missing that does the right thing, and then if you type bare words, suddenly Ruby supports bare words. And in fact, it will even support bare words with bangs in them.

‍

[00:16:10] And this is not deserving of W. A. T. This is actually a result of how awesome Ruby is. But if you ever actually do this, then, W. A. T.

‍

[00:16:22] So looking back clearly, Ruby isn't a tremendously powerful language and it's one of the hallmark facets of Ruby. Doing things just because you can, even though there's sharp edges, not being afraid is really great. Later in that email from Dave Thomas, he explained what it was like to get started with Ruby in 1998.

‍

[00:16:41] He said, I first came across Ruby in 1998. You'd FTP a set of unencoded files, concatenate them, and then UU decode that, typically into a tar file. You'd then run this through tarX and start working on compiling. Ruby had an auto comp file, which helped immensely, and it would work out what libraries you were missing.

‍

[00:16:57] You then entered the recursive hell of installing those, recursive because those libraries would each have their own dependencies, which you'd need to install, et cetera, et cetera. To Matz's credit, Ruby was a fairly simple install. I spent the rest of the day playing with it. I think it was Ruby 1. 2. A fairly simple install.

‍

[00:17:13] I want you to keep this in mind next time you want to complain about RBM, RVM, Homebrew, or any of our fantastically convenient developer tools that we used today. He continued, I fell in love with the language. I felt like it was something I'd been waiting for a long time. At the time, I was writing mostly C, Java, Perl, and Ruby seemed to blow all of them away.

‍

[00:17:30] It was easy to use classes. It had great defaults, metaprogramming. Whatever I threw at it, it shone. So apparently before 2005, it took longer than 15 minutes to build a blog. I had no idea. Sounds awful. This is what Chad Fowler had to say. About that time period, he said, I remember more clearly is the distinct difference between the Rails world and the Ruby world.

‍

[00:17:52] Because when Rails came out, David Hanemeyer Hanson spoke at RubyConf 2004. 64 people in Channel E, Virginia, and a holiday in Select. That was a big one for us. He kept talking about ActionPack, and all these things, and I thought, wow, these are really dumb sounding names. He was just hyping the hell out of Rails before it came out.

‍

[00:18:10] I thought this is silly, because it's an MVC framework in a language no one cared about. So here's that famous DHH Rails demo. What we do is called the Rails command to generate the skeleton of the application. So you saw, it generated a bunch of things a bunch of files, and then the next step, the very next step, is starting the Ruby server.

‍

[00:18:32] Seeing that everything works. The only prerequisite to this is that you have Ruby and Rails installed. Whoops! It worked! Laughter. It's going to say, hello world, and we're going to reload, and hello world. That's how much work you have to do to get to hello world. That's not a lot. Look at all the things I'm not doing.

‍

[00:18:55] Look at all the configuration I'm not writing. All these things are mapped together just automatically. Just by saying blog up here, maps directly to the blogging controller. And just by having index, maps directly to the index. template. Hello from the template. And now we even removed the action and saw that it could go all the way to the template without having an action.

‍

[00:19:17] Scaffolding is a way of easily putting a model object online in a way that you can edit it. Whoops! We didn't create this. This was created for us just by this scaffolding thing. And the view is just mixing code and HTML, which seems like an old fashioned way of doing things, but looks like JSX.

‍

[00:19:42] So whoops became its own Ruby meme around that time. This is a sort of Steve Jobs marketing tactics DHH. Of course the meme's been forgotten because Twitter hadn't been invented yet. But Chad also said this about his perspective of David at the time, and I love this. He's young, and he's thrilled about this, and he loves Ruby, and I see it.

‍

[00:20:02] He's found Ruby, and he's gonna change the world with it. And I'm not somebody who talks about changing the world very much. However, if you go and read the YouTube comments on that particular demo, which I did, a relatively recent comment. At the very beginning, I don't feel any surprise, because these are the common features for every single framework in almost every language today.

‍

[00:20:21] But when I saw the data published, oh my god, this video was published 11 years ago! Which I think crystallizes the entire impact that Ruby did change the world with David and Rails, because now the entire web works like this. It's pretty amazing. But the Ruby world changed too. One of the things that, that David told us was prior to Rails, people who used Ruby were there because they liked the language and the people.

‍

[00:20:44] The pace of innovation was gentle as folks explored opportunities. After Rails, the mood changed. Now Ruby was there to solve a well defined and urgent need, writing web apps. And the Daves teamed up and wrote Agile Web Development with Rails through three editions and three major versions of Rails, and everywhere that I traveled, every software team that was doing Ruby had a bunch of these piled up.

‍

[00:21:04] They were like a an invaluable handbook. Apparently, RubyCon Hawaii was a thing, and I feel like we've regressed a little bit. LAUGHTER That was a fantastic there given by Ben Ornstein about refactoring. I don't want you to think of this as a lecture. This isn't me standing here and telling you all these things that are absolute truth.

‍

[00:21:25] Think of this as pairing. I'm now pair programming with all of you. The first thing to notice is we've gone from one method with two lines to two methods with one line each. Now I'm not going to tell you that's always an improvement, but it usually is. I'm starting to think, these days, that methods longer than a line are a code smell.

‍

[00:21:49] When the code looks like this, for whatever reason, because we're programmers, because we read code, when we see code like this, we read it. So the first thing your eye does when you see, OK, orders and range equals, OK, let me figure out what this is. Let me figure out what this is doing. When it looks like this, when it's its own method, my eye is more likely to see orders within range.

‍

[00:22:08] Okay, that's just a private method. I'm just gonna assume that selects all the orders that are within the date range. What's it do next? Most intermediate object oriented programmers are too reluctant to extract classes. The first rule of classes is that they should be very small. The second rule of classes is that they should be even smaller than that.

‍

[00:22:28] That's it. In most companies, pair programming is a euphemism for co located troubleshooting. But something about the extreme programming root the Ruby community in the West means that like most Ruby companies that, that I visited, I work with, they actually pair program to learn and solve problems. And so don't think that Ben Orenstein read all of that advice in a book.

‍

[00:22:54] No, he like worked day in and day out pair programming with other people and sharpening their craft and that was really something special, something I really admire about the Ruby world. Let's jump to 2007 and the release of Heroku. One of the founders of Heroku, James Lindenbaum, said in an interview, We disagree that those new to Ruby and Rails should have to go learn all the hard stuff.

‍

[00:23:13] It is the frameworks and the platforms that need to shape up and make themselves easier and more accessible. I'll never forget the first time my buddy Mark sat me down to deploy my first Rails app onto Heroku. I ran git push Heroku, and then things happened, and I didn't have to configure anything, and it just worked, and it blew my mind.

‍

[00:23:30] And nowadays, this sort of thing is normal, but in 2007 or whatever, that was really mind blowing. It was really rare. And Heroku was a product, along a lot of other products that were built on top of Rails, that just dispensed with this assumption that friction was okay and that pain was just a natural part of the development process.

‍

[00:23:51] They were very allergic to any sort of extra friction that was being added to developers workflow, and we all benefited from it. So when you look back, especially with Rails, but at some point, Ruby became a massively productive language as well. And I think that high productivity is still a hallmark of lots of Ruby teams.

‍

[00:24:09] Next up is RubyConf San Francisco in 2009, where Ryan Davis and Aaron Patterson showed us that co presenting is a really bad idea. First thing we needed to be able to do was figure out how to identify a bad idea. We came up with this field guide. First and foremost, it needs to be well engineered and tested.

‍

[00:24:27] It needs to be useless ish. It needs to follow Poe's Law. And it needs to have a spiral nature, or what we call Whoops! Ruby, we all know and love, is slow. And C is not. But why would you write in C when you can write in assembly? An example of some inline C for a method called C that counts from 0 to N plus 1 and returns the result.

‍

[00:24:52] Now this needs to be as fast as possible because there are a lot of webpages that have to do this type of counting. So we write this in C so that our webpages are fast. Now, As is obvious, we can see that this assembly code does the exact same thing. Oh, I knew that. I knew it. It's obvious. So really what we need to compare is the benchmarks.

‍

[00:25:16] And as you can see here, Look at that, wow. They're almost exactly the same time. I am blown away. Poobie is a PHP runtime embedded in Ruby.

‍

[00:25:32] I've written a couple web adapters, one for Webrick. Because of course this PHP runtime isn't useful unless we can run, say, WordPress. I'm starting up Frack here down at the bottom, in case you can't read. That starts up Webrick on port LOLOL. So we access that, And then, Create our little configuration file. And whoops! We have a friggin blog. The the correct pronunciation here is Pooby on fails.

‍

[00:26:07] Alright. Alright. So we're gonna start up, this is a normal Rails project, so we're gonna generate, oh, in Rails everything's plural, so we generate the PHP's controller, the controller, right? Yeah. I suppose I could have named that codes, but I don't know if you can consider it codes. So we opened up index.

‍

[00:26:25] php. So we do the phpinfo. I just learned that the other day. Totally. Serious. Port 3000, hit localhost, port 3000, the php's controller, and we're running that. There's a lesson. What Ryan is showing us is speed is important, yes, but it's one of many factors. There are trade offs like readability and writeability, and it's just the case that like, Ruby makes a lot of those trade off decisions, just like Matt was talking about this morning, in a way that like, suits a lot of real world problems just fine the way it is.

‍

[00:27:02] And what Aaron showed us is that just because something has no practical use doesn't mean that it was useless to build it. Maybe it was just simply entertaining to build a PHP runtime in Ruby. But it was probably also a good challenge, and it definitely taught us all a lot. A little. It taught us a little.

‍

[00:27:20] Meanwhile, in Orlando, NVLabs, now CodeSchool, was creating Rails for Zombies. So you're probably wondering, what is Rails for Zombies? The short answer is that it's an interactive tutorial to teach the basics of web application development in the browser using Ruby on Rails. But, here's the long answer.

‍

[00:27:35] In the world of technical learning, you've got books, and you've got screencasts, neither of which has any interactivity. But come on, this is the Nintendo generation. Give me a damn joystick. In this tutorial, we're going to be building a web application somewhat like Twitter, except it's going to be Twitter for zombies.

‍

[00:28:12] So it was a little quirky, but I remember this was so cool. Like typing code into the browser and then you like push enter and it's Whoa, Josh, you did it. Good job. And feeling so successful from that. And especially in an industry that just takes itself way too damn seriously. Most of the time.

‍

[00:28:28] It is something I really love about educators in the Ruby community who are willing to have a little bit of fun and try to find engaging ways to teach people programming. And the code school stuff in Rails for Zombie was a great example of that. By the way, there are zombie emoji now, as of a couple weeks ago, and so I had to put one in my talk.

‍

[00:28:45] And that's all that slide's for. Now for some synergy. In 2004, Y was writing his guide to Ruby. Which was just this, oh, and also you can buy this on Amazon now in a physical copy, so go do that, I guess. This book was it's just so interesting. He mixed like blocks of code with all of these comics in such like a creative and fascinating way.

‍

[00:29:06] And he had amazing ways to show off different code structures. So take a look at this method invocation here. And so this is how Y explained this. He said, Think of it as an inner tube. The method is pulling along, containing its extra instructions. The parentheses form the wet, rounded edges of the inner tube.

‍

[00:29:24] The commas are the feet of each argument, sticking over the edge. So I had never thought of that, but I will never forget that inner tube now. And some people didn't like the kitschy, chunky, bacon thing. They hate fun. But it's almost as if Y was prescient and could see that coming, because at the end of the chapter, the same foxes say, the only thing the world will know me for is chunky bacon, and they're all sad and dejected, which is in hindsight, a really sad slide.

‍

[00:29:57] But the first thing that I encountered that Y built was TryRuby. It was an online REPL that taught you a little bit of Ruby in a 15 minute tutorial. And, nowadays with our modern browsers and these really fantastic JavaScript consoles, it doesn't sound that amazing. But at the time it would send Ruby up to a server and put it in jail.

‍

[00:30:13] It was a really terrific little way to show people Ruby without having to install it. And another one of Y's projects is still alive Shoes, which is a GUI desktop toolkit. for building cross platform apps with Ruby. And Shoes 4 is a release candidate, I think, right now. And tomorrow morning, Jason Clark is giving a talk about Shoes and how to use it.

‍

[00:30:32] So I'd encourage you to go if you're interested. In the Forward to the Pickaxe Boat book, Matt's wrote this. He said, Man is driven to create. I know I really do love to create things. And while I'm not good at painting or drawing or music, I can write software. And there's a reason that like we made p beyond fails and no one in PHP made oh, they made Django

‍

[00:30:57] Anyway, my point is the Ruby community is really creative. In hindsight this one was fantastic. Ruby Ho. Down in 2008, Brian Lyles was talking about testing here. Asking yourself, where do I start? And I'm gonna say test all the fucking time first, but then I'm gonna say you can start at the beginning.

‍

[00:31:16] The Bible says, in the beginning. And in the beginning there was what? No, there was Pearl.

‍

[00:31:31] Today I'll talk about BDD with RSpec, but I like to change things around, so let's just talk about BDD. Or really, let's just talk about testing for us normal people. And the real thing that I'm trying to get out to everyone here is you should be testing all the fucking time. I fell into testing, and this is with good old JUnit.

‍

[00:31:48] And I was, and I thought I was doing real good here, but there was a problem. The problem was I was writing bad brittle tests. And my tests had no organization, and I wasn't using any type of conventions. All my tests looked different every single time. And really I was just confused all over the place.

‍

[00:32:06] Describe what the code should do, rather than describing what it does. And whenever I realize this, I actually, it's it was a moment for me. It's like I, I reached Zen. Remember, test all the fucking time. I can't say this enough. And really, this is what I want everyone to say. When they hear Ruby, I want you to say, Test all the fucking time.

‍

[00:32:24] Yeah! I want to leave you guys with one thought. Do not try to imitate the old master. Seek what they sought. And this is something that I live my life by. And I want to leave you with one more thing.

‍

[00:32:42] So I, again, I think that there's something special about the extreme programming roots in this community combined with the massive popularity of Rails, where Ruby really, in many ways, became the first mainstream language to normalize the idea that you should test your code. And not only test driven development and behavior driven development, but for me working on a Java team, like Ruby really made testing cool.

‍

[00:33:02] We were seriously jealous. Like testing was this drudgery that I had to do as a Java programmer and QA people were treated like second class citizens. I think that like the testing is part of Ruby's history and it really helped push the industry forward. Jump to RailsConf Chicago in 2014. Sandy Metz is talking about making small things here.

‍

[00:33:23] They have noticed some principles, and they developed a style guide about how to organize code. That's what object oriented design is. That's what the rules of object oriented design are. There is, it's a style guide about how to organize code with all the obvious trade offs. All the places where you can make your own decisions.

‍

[00:33:44] This is the squint test. Here's how it works. You squint your eyes, and you lean back, and you look at the code. And we're looking for changes in shape,

‍

[00:33:59] and changes in color. Changes in shape mean you have nested conditionals, and they are always going to be hard to reason about. Changes in color mean that your code is at differing levels of abstraction. Here we have, this is the code we just wrote. This is the squint test version, don't try to read it.

‍

[00:34:16] It's the code we just wrote on the right, this is how we started on the left. You notice that the shape is flat, and the colors are starting to cluster. Kent Beck, who's has a wonderfully succinct way to put this. He says, make the change easy, this might be hard. And then make the easy change. People ask me now, when people ask me how to write object oriented code, I tell them, I give them one small piece of advice.

‍

[00:34:40] I say make smaller things. So I remember back in 2005 when a lot of my Ruby friends were arrogantly laughing at my abstract context factory spring beam stuff and all these heavyweight design patterns in Java land because they didn't need that because Ruby was simple and straightforward.

‍

[00:34:58] And then to watch Sandy's book take off and then in 2014 all of these like Rails developers trying to like jam factory classes into their Rails apps. Was a special kind of pleasure for me. But, to be honest I think that Pooter and teaching and mainstreaming object oriented design to so many people was really a mark of maturity for applications built with Ruby and Rails.

‍

[00:35:18] Thanks to this Ruby Midwest in 2013. Jessica Kerr absolutely blew my mind with this talk on functional programming. Functional programming is a lot about that. It's about all the things we don't have to think about so that we can think about what's right in front of us. And that becomes really important as our applications get larger and more feature rich, and they don't fit all in one person's head anymore.

‍

[00:35:42] You have to be able to put most of the application out of your head and zoom in on what's right in front of you in order to solve these problems effectively. I hear from people who've gone from NET to Ruby is that Ruby developers have a lot of discipline compared to Java and NET programmers. That we, programming Ruby, impose discipline on our code.

‍

[00:36:08] And we do that through idiomatic practices and just avoiding the sticky bits. And we can choose to follow the same functional principles that Haskell imposes on its developers. We can do that of our own choice. Ruby development is consensual.

‍

[00:36:29] So the Ruby community has taught the Java community a crap load of stuff about unit testing and how useful it is. Here's something the Java community can give back. If you have to overwrite methods or inject private state or in any way get around the simple stuff, the stuff that you would do in production code in order to test an object in production code.

‍

[00:36:49] Your object's wrong. Your design is poor. Realize that nil is not data. So the problem with nil is it has 16 different meanings. It means false, it means crap, I screwed something up. It means not applicable. In a hash, it could mean key not found, or it could mean the key contains nil. And when it can mean 16 different things, it means nothing.

‍

[00:37:19] So when I was in college, the idea of functional programming was like this ivory tower, like faux academic nonsense that was really like full of mathematical notation and people puffing their chest, pretending they're smarter than everyone else. How most of us in this room learn functional programming is because Matz thought that these were cool functions to throw on a numerable and wanted to teach them to people, to be useful.

‍

[00:37:40] And so I feel like Ruby was a great gateway drug to real blue collar functional programming. And popularize it in a way that Academia had failed. This is the only talk we're gonna present today that wasn't presented at a Ruby specific conference, but it was given by Jim Wyrick, so we'll give it a pass.

‍

[00:37:58] Okay, so what does that mean? Connascence itself means, it's talking about the common birth of two or more things at the same time, and the production of two things that tend to grow together, that tend to stay the same. Connascence in software, are those things that need to change together. So what is name connascence?

‍

[00:38:18] Suppose you have a definition of a method here called foo, and then we call foo over here. This is connascence of name, because if I decide to change the name of my method foo, I obviously have to change the name of every place where foo is called. where it's defined, and the title has to be there, and the address has to be there.

‍

[00:38:39] So if I were to change the order of my parameters in this list, I would have to change the order of every parameter, or every place it was called, to match the changing of order. Why is Knasense important? Change is expensive. You want to, it's good software practice to reduce the coupling between your modules.

‍

[00:39:02] And Knasense is a way of talking about coupling in a particular way. One of these display, is exactly like the first one, displays all the methods available for the Fixnum class. The other one displays all the methods defined explicitly in the Fixnum, but not in the ancestors of Fixnum. Which one is which?

‍

[00:39:28] Okay, first one's all the way up. How do you remember that? Because please tell me. You just looked it up, okay. I did too, yeah. Since I just looked it up for this talk, I know. But I forget it every single time. This is connascence of meaning. We have assigned a particular meaning to the values true and false that is not evident from their usage right here.

‍

[00:39:52] Actions. Reduce the degree of your connascence in your code. Increase locality. And things that need to change together, put them in the same module. Bring them closer together so they can change together more easily. And, don't repeat yourself is an application of increasing locality. Um, single responsibility principle also moves in that direction.

‍

[00:40:13] So I think these things are based upon the locality idea in Knasense. So that's what coupling means. For me that word just meant nothing until I saw that talk and Jim explained coupling through the term Knasense. It makes me really sad to even have to share that Jim passed away a few years ago.

‍

[00:40:30] But he meant so much to the Ruby community from its like, Heady XP days and from the year 2000 onward to shepherding so many of us through like how to build solid, awesome Ruby code. That if you go to his last commit on GitHub, some of you might not know this, like there's thousands of comments thanking Jim for his contributions.

‍

[00:40:47] And somewhere in some github. com template is an if else conditional to print this thank you message. We recommend you go back and watch all of Jim's old talks. And if you do, and you appreciate it, we encourage you to contribute to the WIREC fund. It's a scholarship program that's trying to keep Jim's memory alive, and also help, more people, find the joys in computer science that he did.

‍

[00:41:06] Clearly, Ruby is a really thoughtful language. We spend a lot of time at conferences talking about ways that we can get better at our craft. At RubyConf Charlotte in 2007, Marcel Molina gave a fantastic talk about beauty. There's something deeper than just appearances, that actually dictates what makes something beautiful versus not beautiful.

‍

[00:41:35] The first topic that he brings up is proportion. The next piece is integrity. Third is clarity. And clarity is a simple concept. It's, something is clear and something is simple. That's a simple working definition for what makes something beautiful. Those three parts. Now we're going to apply that to a piece of software to see how this can actually relate to code that we write.

‍

[00:42:06] You can choose one or two. They're intended to all work in concert. And they balance each other out. They're each necessary but none of them are sufficient. I don't know if he uses the word beauty anywhere in the entire book. I don't know. But, if you look at the information he gives you, and you think about the three principles of beauty, almost every piece of information in that book is driving you towards fulfilling one or more of the three principles that go to our working definition of beauty.

‍

[00:42:42] He's setting out to write a book about how to write great software. And it turns out that all the software that you create is Following those principles is also, by this definition of beauty, beautiful software. Lucky for us, Ruby is optimized for beauty. Big time. I'd like to finish just by thanking Mats and the Ruby core team for writing what I think is the most beautiful language I've ever used.

‍

[00:43:15] So I'd like to thank Mats and give him an applause.

‍

[00:43:17] It's no secret surrounding yourself with beautiful code will lead to happy developers. I think it also stands to reason that happy developers make more progress faster. Ask your manager, more progress will lead to more money. And so through the transitive property, this is not like hippy dippy bullshit.

‍

[00:43:34] Beautiful code leads to more money there, I proved it. So this is actually really valuable stuff. In an interview with O'Reilly in 2001, Motz was asked the following. Did you have a guiding philosophy when designing Ruby? And he replied, yes. It's called the principle of least surprise. I believe people want to express themselves when they program.

‍

[00:43:53] They don't want to fight with the language. First day of my first programming internship, the first piece of advice I got was that there's no such thing as a good surprise. And what the person was talking about was even with great tools it's predictable tools that enable flow, and even a good surprise can break you out of it.

‍

[00:44:11] At Cascadia Ruby in 2012, Katrina Owen gave a fantastic talk about how refactoring brings joy. Taken to coming into the office early in the morning and committing random acts of refactoring. Some people are calling this guilt driven development. But really it's not. Refactoring just makes me happy. I found this particular specimen in the dark recesses of that code base.

‍

[00:44:41] It had no tests and there was no documentation. Where do you even begin testing something like this?

‍

[00:44:52] We don't really know what the inputs look like. We certainly don't know what the output looks like. We do know that it's in production and it appears to be working because we haven't had any complaints from the customer about it.

‍

[00:45:08] The easiest way to discover inputs is to just send something Anything, really, into the method and then see what comes back out. We took a piece of undocumented, untested code, and with a bit of hand waving, we got fake assertions to give us the inputs. The inputs gave us the outputs, and the outputs gave us the real assertions.

‍

[00:45:34] Is it perfect? Of course not. Is it better? Hell yeah. We went from this to this in less than 30 steps. But I started optimizing for happiness. I would specifically put something into its own class just so that I could load just that class and nothing else. The feedback loop you get when you have sub second test suites for the thing that you're working on is unbelievable.

‍

[00:46:03] It's a huge enabler for flow. Along the same lines of the emotional layer of productivity with software, Kent Beck at RailsConf a couple years ago in Atlanta shared this. Those emotions are valuable information. Emotions are noisy information, but they're valuable information, and that feeling of, I'm proud of this, means something.

‍

[00:46:23] And that feeling like, oh, I hope nobody ever looks inside this file, that also means something. Remember that email from Dave Thomas earlier? Yes, this Dave Thomas. This is how he closed it. He said, I'm grateful for the excitement that surrounds Ruby, that keeps it fresh and growing. I'm happy for the folks who found a home here.

‍

[00:46:41] Programming is difficult, and programmers deserve to use the tools that they love. So one of my favorite aspects of Ruby is the pursuit of joy and programmer happiness and delight. I'd love for you to look up like Ruby cones at some point soon and work through those exercises. They're great.

‍

[00:46:58] Start a Ruby quiz club with some friends and play through some of the old example quizzes there. Go on Exorcism, go through the Ruby exercises so that you can go and comment and help other people who are trying to learn Ruby. We've only covered 12 talks, there's 2, 172 to go so you got some homework for yourself.

‍

[00:47:13] We'd love to think about the date you started using Ruby and then use Google Advanced Search and go look for some Ruby blog stuff and see what people were talking about in our community before you joined. And our message to you is we want you to go do something that makes you want to say whoops.

‍

[00:47:27] Cause the last facet of Ruby's future is really going to be determined by people like you in this room. So yeah, we work for Test Double. We're an agency. We're way over time. We'd love for you to join the team at that URL. Like I said, all these links are going to be up at our blog in just a little bit here.

‍

[00:47:41] And thank you so much for sitting through with us.

‍

Related Insights

Explore our insights

See all insights

Developers

What happens when code reviews aren’t mandatory? An experiment

Code reviews can feel like bottlenecks, slowing progress and increasing frustration. BridgeCare flipped the script with an experiment to make code reviews optional.

Andrew Walker

Developers

Should code reviews be mandatory? A look at non-blocking reviews

Are mandatory code reviews a bottleneck for your team? Here's how non-blocking reviews can foster trust, accelerate development, and reduce frustration.

Andrew Walker

Leadership

Survey: AI is here—and it’s reshaping product management

A new report from the Pragmatic Institute reveals how AI is transforming product management and driving growth. Here are the insights, adoption challenges, and the skills product leaders need to master AI and lead with intent.

Test Double Editorial Board

Join the conversation

Technology is a means to an end: answers to very human questions. That’s why we created a community for developers and product managers.

Explore the community

Learn about our team

Like what we have to say about building great software and great teams?

Get to know us