Post #88

There's Nothing.new

Under the Sun

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

The transcript of the talk follows:

[00:00] - Alright, this presentation is titled
[00:02] There's Nothing New Under the Sun.
[00:05] It is the first in a track, a three-part track
[00:09] that you are experiencing called The Future of Ruby.
[00:11] So let's hear a little bit about Ruby's future.
[00:14] - In the future
[00:16] (audience laughing)
[00:17] Ruby will become more popular.
[00:20] There will be more implementations, and there will be
[00:23] more programmers using it.
[00:25] More machines with it installed by default,
[00:28] and more people writing blogs about it.
[00:30] There will also be more people reading blogs about it.
[00:34] I know this is getting crazy but, you have
[00:36] to trust me because I'm keynoting.
[00:38] (audience laughing)
[00:40] So that was 2008, Ruby Hoedown, Chris Wanstrath,
[00:42] the CEO of GitHub, telling us a little bit
[00:44] about what the future would be like.
[00:46] This presentation is the future of Ruby,
[00:48] Part One, The Past.
[00:50] (audience laughing)
[00:52] And at the heart of all of my talks that
[00:54] I present to Ruby conferences, I'm asking the question
[00:57] why do we choose Ruby?
[00:58] I feel like we need to constantly
[01:01] reevaluate this and justify it and come up
[01:03] with good answers, and to be honest,
[01:05] that answer has evolved over time.
[01:07] For example, if it was before 1998,
[01:09] odds are you knew Japanese.
[01:12] If you picked up Ruby in '98,
[01:13] you were literally Dave Thomas.
[01:15] (audience laughing)
[01:17] Not that Dave Thomas, mind you, for the younger people,
[01:19] no, the one that wrote the Pragmatic Programmer
[01:21] with Andy Hunt.
[01:23] If you came in before 2005, you're probably
[01:24] really into Extreme Programming
[01:26] like test-driven development.
[01:28] In 2005, it was all about Rails, as was 2008 and 2012.
[01:33] (audience laughing)
[01:34] And if you're learning Ruby today for the first time,
[01:37] it's probably because your manager was
[01:39] a big fan of Rails back in their day.
[01:40] (audience laughing)
[01:43] But that oversimplifies things a little bit,
[01:44] so I'll share some of my perspective.
[01:46] I came to Ruby first in 2005.
[01:49] I was working through Kent Beck's Extreme Programming book,
[01:52] learning test driven development and loving it.
[01:54] I was writing a lot of Java, or I should say,
[01:56] I was writing a lot of XML and curly braces
[01:58] and not getting a lot done.
[02:00] I was also writing a lot of PHP and slinging
[02:02] thousands of lines of code that I had no hope
[02:04] of maintaining.
[02:05] And I studied in Japan that year,
[02:07] and I genuinely, like, my Japanese friends
[02:08] were really excited about the worldwide notoriety
[02:11] that this little programming language
[02:12] called Ruby was gaining.
[02:14] But if I ask the same thing about somebody in 2017,
[02:16] like, why do they choose Ruby nowadays?
[02:18] I mean, PHP has a perfectly suitable web framework.
[02:22] Java does as well.
[02:24] Microsoft with .NET has embraced open source
[02:27] all of a sudden, and even the Mac.
[02:30] To most people, if you wanna teach them how
[02:31] to program, they're being handed Node and React
[02:33] by default as opposed to Rails these days.
[02:36] Elixir and Elm kind of have a lot of the mojo,
[02:38] the new hotness.
[02:39] If you wanna do functional, you can do backend
[02:41] and frontend Clojure.
[02:42] PLT nerds love Rust, and some people use Go.
[02:46] (audience laughing) (applause)
[02:50] So, this talk is really a retrospective.
[02:53] I wanna talk about the things that drew people
[02:54] to Ruby originally, cause if we rediscover that,
[02:57] it'll help orient us about
[02:59] where we wanna take Ruby from here.
[03:01] But honestly, that sounded like a lot of work.
[03:03] There's over 2100 Ruby talks on Confreaks alone.
[03:08] And soon this is gonna be one of them.
[03:11] And I frankly, I just needed some help,
[03:12] so as an employer, I pulled a Mystery Science Theater 3000
[03:16] move, and locked one of my colleagues in a room
[03:18] for three months to do nothing but watch Ruby talks.
[03:22] His name is Josh Greenwood, and he came to Ruby
[03:25] a little later, in like 2012.
[03:26] And at that point, Rails was the default web framework
[03:29] choice in the industry.
[03:31] In a lot of ways, we'd reached a point
[03:33] of maturity with Sandi's object-oriented design book
[03:36] getting a lot of steam and attention.
[03:38] That was also right after Rails shipped the asset pipeline,
[03:41] which solved the problem of JavaScript packaging
[03:44] once and for all.
[03:45] (audience laughing)
[03:46] And it was also the height of the great coupon wars,
[03:49] where everyone I knew who practiced Ruby worked at either
[03:52] Groupon or LivingSocial,
[03:53] if they didn't already work at GitHub.
[03:57] So I'd like to welcome Josh up to the stage.
[03:59] (applause)
[04:05] - Thank you so much for having me.
[04:07] So let me tell you a little bit
[04:08] about my very naive plan.
[04:10] So I thought maybe I'd just go back
[04:11] and watch RubyConf videos from the first couple
[04:13] years of RubyConf.
[04:14] What Justin failed to tell me is they didn't actually
[04:15] start recording those until 2007.
[04:18] So that was a bummer.
[04:19] So I thought, "well, maybe I'll go check out
[04:20] "some early versions of Ruby
[04:22] "and see if I can get those to compile."
[04:24] That did not go well for me at all. (laughs)
[04:27] So then I thought, I was getting frustrated,
[04:28] I thought, "well, where's the internet store
[04:30] "all of its most valuable knowledge?"
[04:31] Well, Twitter, of course.
[04:33] So I thought, "maybe I'll go see what DHH
[04:35] was talking about when he first announced Rails."
[04:38] Yeah, so you might be thinking to yourself,
[04:40] "Josh, Twitter was not around back then."
[04:42] And you would be totally right.
[04:44] (audience laughing)
[04:46] So I was clearly missing some of the context
[04:48] of the things that came before me.
[04:49] And I suspect some of the room might be as well.
[04:52] So today my goal is to share some of the blog posts,
[04:54] the talks, the exercises, and the conversations
[04:57] we had with folks in the Ruby community,
[04:59] try to unearth some of what drew people
[05:01] to Ruby in the first place.
[05:02] - Cause our goal, really, is to reflect
[05:05] on these various facets of what made us all
[05:07] fall in love with Ruby and its community
[05:10] and to make it just the awesome language
[05:12] ecosystem that it is, so that we can think hard
[05:15] about what we wanna do to take it forward.
[05:17] But as a result, this talk is not an entree.
[05:20] We're not gonna be up here with some big rhetoric
[05:22] trying to convince you of something.
[05:23] Rather, these are mere appetizers
[05:25] showing you some of Josh and my favorite talks
[05:28] and blog posts and ideas from the past,
[05:32] hoping to get you to engage with those, too.
[05:34] And so please don't fret over all
[05:36] of the individual URLs and stuff
[05:38] and trying to take a picture of the screen or something.
[05:40] We're gonna post to our blog right after the talk
[05:43] sources of every single thing that we reference.
[05:45] So just keep an eye out for that later today.
[05:49] All right, without any further ado, let's sit back,
[05:51] and Josh, show me what you got.
[05:53] - So let's start at RubyConf Orlando in 2008.
[05:55] Matz is speaking.
[05:58] - Why we choose Ruby?
[06:00] And everyone has theories on independent reasons
[06:03] for choosing Ruby.
[06:05] For me, it's very simple.
[06:07] It is my beloved masterpiece, you know?
[06:09] (audience laughing)
[06:11] Why we choose Ruby, just because Ruby on Rails.
[06:14] (audience laughing)
[06:17] Could you raise your hand if you're going
[06:19] to stay in Ruby on Rails
[06:21] and not interested in Ruby itself?
[06:25] No, yes, this is Ruby Conference.
[06:28] Love is a great power behind Ruby.
[06:32] And it is the very reason behind Ruby, I'd argue.
[06:39] And I love people using Ruby.
[06:41] And I love people who love Ruby.
[06:44] And I love you all.
[06:49] - So Matz said that this acronym embarrasses him.
[06:53] But MINASWAN, Matz Is Nice And So We Are Nice,
[06:57] was so important to the Ruby community as it became today.
[07:01] He set the tone as the language designer.
[07:03] You don't see very many language designers
[07:05] give keynotes like that, right?
[07:07] But that kind and welcoming spirit
[07:09] is one of my favorite things about Ruby.
[07:12] - Let's jump to Scotland RuyConf in 2011.
[07:15] Our friend Chad Fowler's speaking here.
[07:19] - Who here is in the service industry?
[07:24] All right, actually you're all in the service industry.
[07:27] So everyone who didn't raise your hand, you're wrong.
[07:28] Everyone who was sitting next to them,
[07:31] give them a funny look.
[07:34] Our jobs are to be like an adventure tour guide
[07:37] for our customers, so take them into these scary places,
[07:40] allow them to feel the thrill of whatever
[07:42] it happens to be that we're doing,
[07:44] not to treat them like idiots and make them
[07:47] stay in like a rubberized room
[07:50] so they can't mess anything up,
[07:52] but to allow them to get as close as they want
[07:54] to the edge, and make it safe for them to do that.
[07:58] Other thing that everyone else is mentioning
[08:00] in this conference is Corey Haines.
[08:02] (audience laughing)
[08:04] Here's a tweet that Corey did recently.
[08:07] "Contemplating what practices could constitute
[08:09] "a list of required practices of modern
[08:10] "software development."
[08:12] So you're probably all thinking unit testing, right?
[08:15] And source control, et cetera, et cetera, et cetera.
[08:17] Justin Gatelyn says, "giving a shit,
[08:20] "actually, really giving a shit,
[08:22] "knowing the first thing about coding,"
[08:24] and then, "giving a shit."
[08:26] (audience laughing)
[08:27] And I thought, "that is pretty deep."
[08:28] (audience laughing)
[08:32] He said a Lexus dealership was his best experience,
[08:35] which was not all that helpful,
[08:36] so I said, "in what way?"
[08:38] And he said this: "the feeling that they do
[08:40] "10 minutes of work to save you one minute of your time."
[08:46] And then I think the most important piece
[08:50] of this caring like crazy goal that I have
[08:55] in my new job and therefore in my new life here
[08:59] is to kill cynicism wherever I can.
[09:05] But rather than be cynical about that stuff,
[09:07] why don't you just fix it?
[09:09] Cynicism is laziness.
[09:12] Speaking of Dave, in The Pragmatic Programmer,
[09:14] Dave and Andy have one of their little snippets,
[09:17] I think they call them tips, that says,
[09:19] "always answer every email that you get,"
[09:22] which kinda sounds stupid.
[09:23] Like, is that really a bullet
[09:24] and one of the major headings in The Pragmatic Programmer,
[09:28] the classic, the computer programming classic?
[09:30] And it is.
[09:31] And the funny thing is, that might be
[09:32] the only one I can remember, having read it 10 years ago.
[09:36] I remember thinking it was weird, though,
[09:37] when I first read it.
[09:38] But it's such great advice.
[09:40] And when you're someone like Dave,
[09:43] he did answer my email, you know?
[09:45] In fact, I think that's why I emailed him,
[09:47] because I knew he was going to answer it.
[09:49] (audience laughing)
[09:52] - So we emailed Dave Thomas.
[09:54] (audience laughing)
[09:56] We asked, "what was the early Ruby community like
[09:59] "in the West?"
[10:01] He said, "well, there was a mailing list.
[10:02] "It was mostly in Japanese, but English speakers
[10:04] "were encouraged to post, too, and folks would reply.
[10:06] "Often we found ourselves communicating
[10:08] "purely through code.
[10:09] "Someone would post a broken test,
[10:11] "and one of the maintainers would either correct
[10:12] "the test or correct Ruby.
[10:15] "I started by asking Matz's permission to write the book.
[10:18] "He was enthusiastic and helped an incredible amount,
[10:20] "answering hundreds of questions
[10:21] "and occasionally changing the language
[10:22] "or libraries as I found edge cases."
[10:25] That book, by the way, is the PickAxe book.
[10:27] And if you haven't seen it, this was an indispensable
[10:30] API reference and guide for anyone
[10:32] using Ruby through the mid-oughts.
[10:35] "The book was published at the end of '99
[10:36] "and led to the first international Ruby Conference
[10:38] "the following year in Florida.
[10:40] "There were 30 to 40 people there,
[10:41] "including folks from Japan and Europe."
[10:44] So the moral of the story is that
[10:47] if you ever need help, just email Dave Thomas.
[10:49] And he'll reply to you.
[10:51] - Let's jump to 2007.
[10:53] Ryan Bates had just started producing RailsCasts.
[10:55] He basically got me through my first job.
[10:59] (computer keys clicking)
[11:07] - [Ryan] Well, this is where Rails 2.0
[11:09] comes in really handy, because you get
[11:11] this new rake task called db:create.
[11:14] And this will create the database
[11:16] for the current environment.
[11:19] - [Man] Whoa!
[11:20] (audience laughing)
[11:21] - [Ryan] There's a lot of fancy new additions
[11:22] to migrations in Rails 2, which will really
[11:25] save us a lot of time.
[11:28] Also, this t.timestamps here,
[11:31] what this will do is add a created at
[11:33] and updated at columns to this table,
[11:35] because Rails assumes you pretty much always want that.
[11:38] - That's a lie.
[11:39] I wish that Rails would just do timestamps by default
[11:41] and I had to say like opt out of timestamps,
[11:43] cause I always forget it for the first month.
[11:47] But you know what, a lot of people
[11:50] over the years have complained to various degree
[11:52] that Rails is too magic.
[11:54] But if you were really in the Ruby community,
[11:57] in the Rails community, no.
[11:58] You just didn't watch enough RailsCasts.
[12:00] That explains most of everything.
[12:01] (audience laughing)
[12:03] And that complaint is valid in that yeah,
[12:05] there was a ton of tribal knowledge.
[12:07] Ruby's dynamic, it was maybe under-documented.
[12:10] Things were definitely moving really, really fast.
[12:12] But there was an unintended side effect
[12:14] of all that tribal knowledge, which is that
[12:16] it forced us to create tribes.
[12:19] And I don't think that we really appreciate the fact
[12:21] that Ruby has more local meetups and regional conferences
[12:24] than any other language its size.
[12:26] And it's because the way that the language works
[12:29] and how all of our libraries are constructed
[12:31] require us to talk to each other.
[12:33] And I think that's really special.
[12:35] In fact, when I look back, there's something
[12:37] about Ruby, and the language and the tools
[12:40] and the community, that's just really, really kind
[12:42] and welcoming.
[12:43] And it's one facet I really appreciate.
[12:46] - In 2004, a blog post called Tour de Babel
[12:48] was written by Steve Yegge.
[12:50] And here's what he had to say about Ruby.
[12:52] "Ruby took Perl's string processing
[12:53] "and Unix integration as-is, meaning the syntax
[12:56] "is identical.
[12:57] "So right there, before anything else happens,
[12:59] "you already have the best of Perl.
[13:01] "And that's a great start, especially
[13:02] "if you don't take the Rest of Perl.
[13:03] (audience laughing)
[13:05] "But then Matz took the best of list processing from Lisp,
[13:08] "the best of OO from Smalltalk and other languages,
[13:10] "and the best of iterators from CLU,
[13:12] "and pretty much the best of everything from everyone.
[13:14] "And he somehow made it all work together
[13:16] "so well you don't even notice that it has all that stuff.
[13:20] "I learned Ruby faster than any language,
[13:23] "out of 30 or 40 total.
[13:24] "It took me about three days before I was more comfortable
[13:26] "using Ruby than I was in Perl,
[13:27] "after eight years of Perl hacking."
[13:31] - One of the things I've always loved about Ruby
[13:33] is that it has all of these features
[13:35] but constrains the developer with almost no rules
[13:39] as to how to use them.
[13:40] So it is dangerous.
[13:42] But it also trusts the developer to express themselves.
[13:44] And very few other languages, even the other hip
[13:47] and trendy languages of our day, check both of these boxes.
[13:50] I think Ruby stills stands out.
[13:52] - Next is MountainWest Ruby in 2008.
[13:54] Giles Bowkett is speaking here.
[13:56] - And that's Zed Shaw flipping off Giles.
[14:00] - One of the things that Ruby is famous for
[14:01] is metaprogramming, right, which is programming
[14:04] programming itself.
[14:05] But the thing is, that's not usually
[14:06] what we really do when we're doing metaprogramming,
[14:08] this magic, right?
[14:10] Because it's not metaprogramming.
[14:11] It's just programming.
[14:13] What we're really doing is metaOO.
[14:16] What it does is if you add a method to an object,
[14:18] it says, "I am in yourself, adding your name."
[14:21] Okay, I'm in your oatmeal, adding your cranberries.
[14:24] That's kind of eccentric.
[14:26] (audience laughing)
[14:28] - Giles is kind of eccentric.
[14:31] - I just took those, "I'm in your X adding your Y,"
[14:33] "I'm creating a new whatever,"
[14:35] I took that and I just changed it
[14:36] to return Ruby code, right?
[14:39] So now instead of printing random text
[14:41] to the screen like a log file,
[14:42] what it's doing is it's creating code.
[14:45] Now, there's no reason that you couldn't
[14:46] put executable code in a log file.
[14:50] When you run it, you end up with Python
[14:52] that populates a graph drawing program for Node Boxer,
[14:56] and this is what that graph looks like.
[14:58] And obviously, it is not stunning, right?
[15:00] It is not gorgeous.
[15:01] It is a simple object graph.
[15:04] Read this book, and I've only ever heard one
[15:07] other person or read one other person say that.
[15:09] The other person who said that is David Heinemeier Hansson.
[15:13] Now, the way this book starts
[15:14] is it starts with an EJB application, right?
[15:16] It was 2003.
[15:18] You've got a legacy app with 150 tables.
[15:22] You're using EJB, so you need seven files
[15:24] for every table that you wanna grok with your app.
[15:28] So that comes out, seven times 150,
[15:31] that comes out to 1,050 Java files, right?
[15:35] By hand, that takes a very long time to create.
[15:37] With generators, he created it very, very swiftly.
[15:42] Everybody who talks about Rails is,
[15:44] they're like, "magic makes programmers more productive."
[15:47] Bullshit, code generation makes programmers more productive.
[15:53] - Oh, we emailed Chad Fowler, too.
[15:56] And he's right there, and he also replied to our email.
[16:00] One of the kind of things that kept coming up
[16:02] is code generation.
[16:03] He had this to say: "And then I started doing stuff
[16:06] "like building DSLs to generate code,"
[16:08] in his case Java, "so I could write code in Ruby
[16:10] "and no one would have to know that it was Ruby.
[16:13] "It's true, everyone was doing code generation
[16:15] "in Ruby back then."
[16:16] And in the back of my mind, I'm just imagining
[16:18] how funny it is that before Rails,
[16:20] one of the core use cases for Ruby
[16:22] was to generate other programming language code
[16:24] so that people didn't have to know
[16:26] you were writing Ruby.
[16:28] And so we've come a long way.
[16:30] - Next up is Codemash in 2012,
[16:32] a talk given by Gary Bernhardt,
[16:34] the guy who sells screencasts at Destroy All Software.com.
[16:37] - And this is what his website looked like
[16:39] after he learned CSS.
[16:40] (audience laughing)
[16:43] - This has got to be one of the best lightning talks
[16:44] ever given, at least that I've watched.
[16:47] - [Gary] Let's talk about Ruby.
[16:49] (audience laughing)
[16:51] Ruby, unlike some other dynamic languages,
[16:53] does not have bare words.
[16:55] So you cannot just type words in and have strings come out,
[16:58] unless you define a particular method_missing
[17:01] that does the right thing.
[17:03] And then if you type bare words,
[17:05] suddenly Ruby supports bare words.
[17:07] And in fact, it will even support bare words
[17:08] with bangs in them.
[17:11] And this is not deserving of Wat.
[17:13] This is actually a result of how awesome Ruby is.
[17:16] (audience laughing)
[17:17] But if you ever actually do this, then wat.
[17:21] (audience laughing)
[17:24] - So looking back, clearly Ruby
[17:26] is a tremendously powerful language,
[17:28] and it's one of the hallmark facets
[17:29] of doing things just because you can.
[17:32] Even though there's sharp edges,
[17:33] not being afraid is really great.
[17:36] - Later in that email from Dave Thomas,
[17:38] he explained what it was like to get started
[17:39] with Ruby in 1998.
[17:42] He said, "I first came across Ruby in 1998.
[17:45] "You'd ftp a set of unencoded files,
[17:47] "concatenate them, and then uudecode that,
[17:50] "typically into a tar file.
[17:51] "You'd then run this through tar x
[17:53] "and start working on compiling.
[17:55] "Ruby had an autoconf file, which helped immensely,
[17:57] "and it would work out what libraries you were missing.
[17:59] "You then entered the recursive hell
[18:00] "of installing those, recursive because those libraries
[18:02] "would each have their own dependencies,
[18:04] "which you'd need to install, et cetera, et cetera.
[18:07] "To Matz's credit, Ruby was a fairly simple install.
[18:09] "I spent the rest of the day playing with it.
[18:11] "I think it was Ruby 1.2."
[18:13] - A fairly simple install, I want you to keep this
[18:15] in mind next time you wanna complain about rbenv,
[18:18] rvm, homebrew, or any of our fantastically convenient
[18:21] developer tools that we use today.
[18:23] - He continued, "I fell in love with the language.
[18:25] "I felt like it was something I'd been waiting for,
[18:27] "waiting for a long time.
[18:28] "At the time I was writing mostly C, Java, Perl,
[18:31] "and Ruby seemed to blow all them away.
[18:33] "It was easy to use classes, it had great defaults,
[18:35] "metaprogramming, whatever I threw at it, it shone."
[18:40] So apparently before 2005, it took longer than 15 minutes
[18:42] to build a blog.
[18:43] I had no idea.
[18:44] (audience laughing)
[18:46] Sounds awful.
[18:47] This is what Chad Fowler had to say
[18:48] about that time period.
[18:50] He said, "I remember more clearly
[18:52] "is the distinct difference between the Rails world
[18:54] "and the Ruby world, because when Rails came out,
[18:56] "David Heinemeier Hansson spoke at RubyConf 2004.
[18:59] "64 people in Chantilly, Virginia
[19:01] "in a Holiday Inn Select.
[19:02] "That was a big one for us.
[19:05] "He kept talking about ActionPack
[19:06] "and all these things I thought,
[19:07] "wow, these are really dumb-sounding names.
[19:11] "And he was just hyping the hell out of Rails
[19:13] "before it came out.
[19:14] "I thought, this is sort of silly,
[19:15] "because it's an MVC framework
[19:16] "in a language no one cared about."
[19:19] But here's that famous DHH Rails demo.
[19:23] - [Chad] Thing we do is called the Rails command
[19:25] to generate this skeleton of the application.
[19:27] So you saw it generated a bunch of things,
[19:30] a bunch of files, and then the next step,
[19:34] the very next step is starting the Ruby server.
[19:37] So seeing that everything works.
[19:39] The only prerequisite to this is that
[19:41] you have Ruby on Rails installed.
[19:44] Whups, it worked!
[19:46] (audience laughing)
[19:48] It's gonna say hello world.
[19:51] And we're gonna reload, and hello world!
[19:54] That's how much work you had to do
[19:55] to get to hello world.
[19:57] that's not a lot.
[19:59] Look at all the things I'm not doing.
[20:01] look at all the configurations I'm not writing.
[20:03] All these things are mapped together just automatically,
[20:06] just by saying blog up here
[20:08] maps directly to the blogging controller.
[20:10] And just by having index maps directly
[20:12] to the index template, hello world's a template.
[20:16] And now we even remove the action
[20:17] and saw that it could go all the way to the template
[20:19] without having an action.
[20:21] All right.
[20:22] Scaffolding is a way of easily putting
[20:25] a model object online in a way that you can edit it.
[20:29] Whups, we didn't create this.
[20:30] This was created for us just by this scaffolding thing.
[20:34] And the view is just mixing code and HTML,
[20:40] which seems like an old-fashioned way of doing things, but.
[20:45] - [Man] Kind of looks like JSX.
[20:47] - Yeah.
[20:49] - So Wups became its own Ruby meme around that time.
[20:54] It was a sort of Steve Jobs marketing tactics of DHH.
[20:57] Of course, the memes have been forgotten,
[20:58] cause Twitter hadn't been invented yet.
[21:00] (audience laughing)
[21:02] Chad also said this about his perspective of David
[21:04] at the time, which I love this.
[21:06] "He's young, and he's thrilled about this,
[21:08] "and he loves Ruby, and I see it.
[21:10] "he's found Ruby, and he's going
[21:11] "to change the world with it."
[21:12] And I'm not somebody who talks about
[21:14] changing the world very much.
[21:16] However, if you go and read the YouTube comments
[21:18] on that particular demo, which I did,
[21:20] (audience laughing)
[21:22] a relatively recent comment:
[21:23] "At the very beginning, I don't feel any surprise,
[21:25] "cause these are the common features
[21:26] "for every single framework in almost every language today.
[21:29] "But when I saw the date of publish,
[21:30] "oh my god, this video was published 11 years ago!"
[21:33] So I think crystallizes the entire impact
[21:36] that Ruby did change the world
[21:40] with David and Rails, because now the entire web
[21:42] works like this, and it's pretty amazing.
[21:45] But the Ruby world changed, too.
[21:47] One of the things that David told us was,
[21:49] "prior to Rails, people who used Ruby
[21:50] "were there because they liked the language and the people.
[21:53] "The pace of innovation was gentle,
[21:54] "as folks explored opportunities.
[21:56] "After Rails, the mood changed.
[21:58] "Now Ruby was there to solve a well-defined
[22:00] "and urgent need: writing web apps."
[22:03] And so the Daves teamed up and wrote
[22:04] Agile Web Development with Rails,
[22:06] through three editions and three major versions of Rails.
[22:09] And everywhere that I traveled,
[22:11] every software team that was doing Ruby
[22:12] had a bunch of these piled up.
[22:14] They were like an invaluable handbook.
[22:19] - So apparently RubyConf Hawaii was a thing,
[22:21] and I feel like we regressed a little bit.
[22:23] (audience laughing)
[22:27] There was a fantastic thing
[22:28] given by Ben Orenstein about refactoring.
[22:31] - I don't want you to think of this as a lecture.
[22:33] This isn't me standing here and telling you
[22:35] all these things that are absolute truth.
[22:38] Think of this as pairing.
[22:39] I am now pair programming with all of you.
[22:43] The first thing to notice is we've gone
[22:45] from one method with two lines
[22:47] to two methods with one line each.
[22:49] And I'm not gonna tell you that that's always
[22:51] an improvement, but it usually is.
[22:55] I'm starting to think, these days,
[22:57] that methods longer than a line are a code smell.
[23:01] When the code looks like this,
[23:03] for whatever reason, because we're programmers,
[23:04] because we read code, when we see code like this,
[23:07] we read it.
[23:09] So the first thing your eye does
[23:10] when you see, okay, orders_within_range equals,
[23:12] okay, let me figure out what this is.
[23:14] Let me figure out what this is doing.
[23:16] When it looks like this, when it's its own method,
[23:18] my eye is more likely to see orders_within_range,
[23:20] okay, that's just a private method.
[23:22] I'm just gonna assume that selects
[23:23] all the orders that are within the date range.
[23:25] What's it do next?
[23:28] Most intermediate object-oriented programmers
[23:30] are too reluctant to extract classes.
[23:34] The first rule of classes is
[23:36] that they should be very small.
[23:37] The second rule of classes is that
[23:39] they should be even smaller than that.
[23:41] (audience laughing)
[23:44] - In most companies, pair programming
[23:46] is a euphemism for co-located troubleshooting.
[23:49] (audience laughing)
[23:52] But something about the extreme programming roots
[23:55] of the Ruby community in the West
[23:57] means that most Ruby companies that I visit,
[24:00] that I work with, they actually pair program
[24:02] to learn and solve problems.
[24:03] And so don't think that Ben Orenstein
[24:05] read all of that advice in a book.
[24:07] No, he worked day in, day out,
[24:10] pair programming with other people
[24:11] and sharpening their craft.
[24:12] And that was really something special,
[24:13] something I really admire about the Ruby world.
[24:16] - Let's jump to 2007 and the release of Heroku.
[24:19] - One of the founders of Heroku, James Lindenbaum,
[24:21] said in an interview, "we disagree
[24:23] "that those new to Ruby and Rails
[24:25] "should have to go learn all the hard stuff.
[24:27] "It is the frameworks and the platforms
[24:29] "that need to shape up and make themselves
[24:30] "easier and more accessible."
[24:33] I'll never forget the first time my buddy Mark
[24:34] sat me down to deploy my first Rails app onto Heroku.
[24:38] I ran git push heroku, and then things happened,
[24:40] and I didn't have to configure anything,
[24:41] and it just worked.
[24:42] And it blew my mind.
[24:44] And nowadays, this sort of thing is normal.
[24:47] But in 2007 or whatever,
[24:48] that was really, really mindblowing.
[24:50] It was really rare.
[24:51] And Heroku was a product among a lot
[24:56] of other products that were built on top of Rails
[24:57] that just dispensed with this assumption
[25:01] that friction was okay and that pain was just
[25:04] a natural part of the development process.
[25:06] They were very allergic to any sort
[25:08] of extra friction that was being added
[25:10] to developers' workflow.
[25:12] And we all benefited from it.
[25:14] So when you look back, especially with Rails,
[25:16] but at some point, Ruby became a massively
[25:19] productive language as well.
[25:21] And I think that high productivity
[25:23] is still a hallmark of lots of Ruby teams.
[25:25] - Next up is RubyConf San Francisco in 2009,
[25:28] where Ryan Davis and Aaron Patterson
[25:30] showed us that co-presenting is a really, really bad idea.
[25:33] (audience laughing)
[25:36] - What we need is to be able to figure out
[25:38] how to identify a bad idea.
[25:40] We came up with this field guide.
[25:41] First and foremost, it needs to be well engineered
[25:43] and tested.
[25:44] It needs to be useless-ish.
[25:46] It needs to follow Poe's law.
[25:48] And it needs to have a spiral nature,
[25:49] or what we call whups.
[25:52] (audience laughing)
[25:54] - Ruby, we all know and love, is slow.
[25:57] C is not.
[25:58] But why would you write in C when you can write in assembly?
[26:00] (audience laughing)
[26:02] An example of some inline C for a method called C
[26:05] that counts from zero to N plus one
[26:09] and returns the result.
[26:11] Now, this needs to be as fast as possible.
[26:12] There are a lot of webpages that have to do
[26:14] this type of counting.
[26:15] (audience laughing)
[26:16] So we write this is C so that our webpages are fast.
[26:20] Now, as is obvious,
[26:23] (audience laughing)
[26:25] we can see that this assembly code
[26:26] does the exact same thing.
[26:29] - [Aaron] Oh, I knew that, obvious.
[26:32] - So really what we need to compare is the benchmarks.
[26:35] (audience laughing)
[26:36] And as you can see here-
[26:37] - Look at that, wow!
[26:38] - [Ryan] They're almost exactly the same time.
[26:40] - I'm blown away.
[26:42] (audience laughing)
[26:44] Phuby is a PHP runtime embedded in Ruby.
[26:49] (audience laughing)
[26:53] I've written a couple web adaptors,
[26:54] one for WEBRick, cause of course
[26:56] this PHP runtime isn't useful unless we can run,
[26:59] say, WordPress, right?
[27:02] I'm starting up Phrack here down at the bottom,
[27:04] in case you can't read.
[27:05] That starts up WEBRick on port LOLOL.
[27:07] (audience laughing)
[27:12] So we access that, create our little configuration file,
[27:16] and whups, we have a freakin blog.
[27:19] (audience laughing)
[27:27] The correct pronunciation here is "Pooby on Fails."
[27:31] (audience laughing)
[27:35] All right, all right.
[27:38] So we're gonna start up, this is a normal Rails project.
[27:41] So we're gonna generate, oh, in Rails,
[27:44] everything's plural.
[27:45] So we generate the PHPs controller to control it, right?
[27:47] (audience laughing)
[27:50] I suppose I could've named that codes,
[27:51] but I don't know if you can consider it code.
[27:53] So we opened up index.php.
[27:55] (audience laughing)
[27:58] So we do the PHP info.
[28:00] I just learned that the other day, total, serious.
[28:04] So port 3,000, hit localhost, port 3,000,
[28:08] the PHPs controller, and we're running that.
[28:10] (audience laughing) (applause)
[28:14] - There is a lesson.
[28:15] What Ryan is showing us is speed is important, yes.
[28:18] But it's one of many factors.
[28:20] There are trade offs, like readability and writability.
[28:22] And it's just the case that Ruby
[28:24] makes a lot of those trade off decisions,
[28:26] just like Matz was talking about this morning,
[28:28] in a way that suits a lot of real-world problems
[28:30] just fine the way it is.
[28:32] And what Aaron showed us is that just because
[28:34] something has no practical use doesn't mean
[28:36] that it was useless to build it.
[28:39] Maybe it was just simply entertaining to build
[28:41] a PHP runtime in Ruby.
[28:43] But it was probably also a good challenge.
[28:45] And it definitely taught us all a lot,
[28:48] a little, it taught us a little.
[28:49] (audience laughing)
[28:51] - Meanwhile, in Orlando, Envy Labs,
[28:53] now Code School, was creating Rails for Zombies.
[28:57] - [Voiceover] So you're probably wondering
[28:58] what is Rails for Zombies?
[28:59] Well, the short answer is that it's an interactive tutorial
[29:01] to teach the basics of web application development
[29:03] in the browser using Ruby on Rails.
[29:05] But here's the long answer.
[29:07] In the world of technical learning,
[29:08] you've got books and you've got screencasts,
[29:10] neither of which has any interactivity.
[29:12] But come on, this is the Nintendo generation.
[29:14] Give me a damn joystick.
[29:17] (upbeat music)
[29:18] - [Singer] Zombie brains and you're entranced.
[29:20] Time to stop and learn some Rails,
[29:23] cause we got something new to grab.
[29:26] Rails for Zombies by Envy Labs.
[29:30] (audience laughing)
[29:31] - In this tutorial, we're gonna be building
[29:33] a web application somewhat like Twitter,
[29:36] except it's going to be Twitter for zombies.
[29:42] (audience laughing)
[29:44] - So it was a little quirky, but I remember
[29:45] this was so cool, typing code into the browser,
[29:48] and then you push enter, and it's like, whoa,
[29:49] Josh, you did it, good job,
[29:51] and feeling so successful from that.
[29:54] - And especially in an industry
[29:55] that just takes itself way too damn seriously
[29:58] most of the time, it is something
[30:00] I really love about educators in the Ruby community
[30:04] who are willing to have a little bit of fun
[30:05] and try to find engaging ways to teach people programming.
[30:09] And the Code School stuff and Rails for Zombies
[30:11] was a great example of that.
[30:12] By the way, there are zombie emoji now,
[30:15] as of like a couple weeks ago.
[30:16] And so I had to put one in my talk.
[30:18] (audience laughing)
[30:19] And that's all that slide is for.
[30:20] - Now for some synergy.
[30:22] In 2004, why was writing his guide to Ruby,
[30:25] which was just this, oh, and also
[30:28] you can buy this on Amazon now,
[30:29] in a physical copy, so go do that, I guess.
[30:33] This book was just so interesting.
[30:36] He mixed blocks of code with all of these comics
[30:39] in such a creative and fascinating way.
[30:41] And he had amazing ways to show off
[30:43] different code structures.
[30:46] So take a look at this method invocation here.
[30:49] And so this is how why explains this.
[30:51] He said, "think of it as an inner tube
[30:53] "the method is pulling along,
[30:54] "containing its extra instructions.
[30:56] "The parentheses form the wet,
[30:58] "well-rounded edges of the inner tube.
[30:59] "The commas are the feet of each argument
[31:02] "sticking over the edge."
[31:04] So I've never thought of that,
[31:05] but I will never forget that inner tube now.
[31:07] (audience laughing)
[31:10] - And some people didn't like the kitschy
[31:12] chunky bacon thing, you know, they hate fun.
[31:16] But it's almost as if why was prescient
[31:19] and could see that coming, cause at the end of the chapter,
[31:21] the same foxes say, "the only thing the world
[31:24] "will know me for is chunky bacon."
[31:27] And they're all sad and dejected,
[31:29] which is, in hindsight, a really sad slide.
[31:33] (audience laughing)
[31:34] But the first thing that I encountered
[31:35] that why built was Try Ruby.
[31:38] It was an online REPL that taught you
[31:40] a little bit of Ruby in a 15-minute tutorial.
[31:42] And nowadays, with our modern browsers
[31:44] and these really fantastic JavaScript consoles,
[31:46] it doesn't sound that amazing.
[31:48] But at the time, it would send Ruby
[31:50] up to a server and put it in jail.
[31:51] It was a really, really terrific
[31:53] little way to show people Ruby
[31:54] without having to install it.
[31:56] And another one of why's projects is still alive.
[31:59] Shoes is a GUI desktop toolkit
[32:02] for building cross-platform apps with Ruby.
[32:05] And Shoes 4 is a release candidate I think right now,
[32:07] and tomorrow morning Jason Clark is giving a talk
[32:10] about Shoes and how to use it.
[32:12] So I encourage you to go if you're interested.
[32:15] - In the forward to the PickAxe book, Matz writes this.
[32:19] He says, "man is driven to create.
[32:21] "I know I really do love to create things.
[32:23] "and while I'm not good at painting
[32:24] "or drawing or music, I can write software."
[32:28] - And there's a reason that we made Phuby on Phails
[32:33] and no one in PHP made, oh, they made Django.
[32:38] (audience laughing)
[32:40] Anyway, my point is the Ruby community's really
[32:42] creative, in hindsight.
[32:45] - This one is fantastic.
[32:46] Ruby Hoedown, 2008, Bryan Liles
[32:48] is talking about testing here.
[32:52] - Asking yourself, "where do I start?"
[32:54] And I'm gonna say test all the fucking time, first.
[32:56] But then I'm gonna say you just start at the beginning.
[33:00] The bible says, "in the beginning."
[33:01] And in the beginning, there was what?
[33:03] - [Audience Member] God!
[33:04] - No, there was Perl.
[33:05] (audience laughing)
[33:15] Today I'll talk about BDD with RSpec,
[33:17] but I like to change things around,
[33:18] so let's just talk about BDD.
[33:20] Or really, let's just talk about testing
[33:21] for us normal people.
[33:23] And the real thing that I'm trying to get
[33:24] out to everyone here is you should
[33:26] be testing all the fucking time.
[33:30] I fell into testing, and this is with good old JUnit.
[33:33] And I thought I was doing real good here.
[33:35] But there was a problem.
[33:37] Wow, problem was I was writing bad, brittle tests.
[33:40] And my tests had no organization.
[33:43] And I wasn't using any type of conventions.
[33:45] All my tests looked different every single time.
[33:48] And really I was confused, all over the place.
[33:52] Describe what the code should do
[33:54] rather than describing what it does.
[33:56] And whenever I realized this, I actually,
[33:58] it's like it was a moment for me.
[34:00] And it was like I reached zen.
[34:03] And remember, test all the fucking time.
[34:05] and I can't say this enough.
[34:06] And really this is what I want everyone to say.
[34:08] When I hear Ruby, I want you to say,
[34:09] "test all the fucking time, yeah!"
[34:11] (audience laughing)
[34:14] I'm gonna leave you guys with one thought.
[34:16] "Do not try to imitate the old masters.
[34:20] "Seek what they sought."
[34:22] And this is something that I live my life by.
[34:24] And I wanna leave you with one more thing.
[34:26] (audience laughing)
[34:29] - So again, I think there's something special
[34:31] about the Extreme Programming roots in this community,
[34:34] combined with the massive popularity of Rails,
[34:37] where Ruby really in many ways
[34:38] became the first mainstream language
[34:41] to normalize the idea that you should test your code.
[34:44] And not only test-driven development
[34:47] and behavior-driven development,
[34:48] but for me, working on a Java team,
[34:50] Ruby really made testing cool.
[34:52] We were seriously jealous.
[34:53] Testing was this drudgery that I had to do
[34:55] as a Java programmer, and QA people
[34:57] were treated like second-class citizens.
[34:59] I think that the testing is part of Ruby's history,
[35:02] and it really, really helped push the industry forward.
[35:06] - Jump to RailsConf Chicago in 2014.
[35:09] Sandi Metz is talking about making small things here.
[35:13] - May have noticed some principles.
[35:15] And they developed a style guide
[35:18] about how to organize code.
[35:21] That's what object-oriented design is.
[35:23] That's what the rules of object-oriented design are.
[35:25] It's a style guide about how to organize code,
[35:28] with all the obvious trade offs,
[35:30] all the places where you can make your own decisions.
[35:34] This is the squint test.
[35:36] (audience laughing)
[35:38] Here's how it works.
[35:39] You squint your eyes, and you lean back,
[35:42] and you look at the code.
[35:44] And we're looking for changes in shape.
[35:47] (audience laughing)
[35:50] And changes in color.
[35:53] Changes in shape mean you have nested conditionals,
[35:55] and they are always gonna be hard to reason about.
[35:58] Changes in color mean that your code
[35:59] is at differing levels of abstraction.
[36:03] Here we have, this is the code we just wrote.
[36:05] And this is the squint test version.
[36:06] Don't try to read it.
[36:07] It's code we just wrote on the right.
[36:08] This is how we started on the left.
[36:10] You notice that the shape is flat
[36:13] and the colors are starting to cluster.
[36:16] Tidbeck, who has a wonderfully succint way to put this.
[36:19] He says, "make the change easy; this might be hard.
[36:23] "And then make the easy change."
[36:25] People ask me now, when people ask me
[36:27] how to write object-oriented code,
[36:28] I tell them, I give them one small piece of advice.
[36:32] I say, "make smaller things."
[36:35] - So I remember back in like 2005,
[36:38] when a lot of my Ruby friends were arrogantly laughing
[36:40] at my abstract context factory springbeam stuff
[36:44] and all these heavyweight design patterns in Java land
[36:48] because they didn't need that,
[36:49] cause Ruby was simple and straightforward.
[36:51] And then to watch Sandi's book take off,
[36:53] and then in like 2014 all of these Rails developers
[36:56] trying to jam factory classes into their Rails apps
[36:59] was a special kind of pleasure for me.
[37:02] (audience laughing)
[37:02] But to be honest, I think that POODR and teaching
[37:05] and mainstreaming object-oriented design
[37:08] to so many people was really a mark of maturity
[37:12] for applications built with Ruby and Rails.
[37:15] - Next is Ruby Midwest in 2013.
[37:17] Jessica Kerr absolutely blew my mind
[37:18] with this talk on functional programming.
[37:20] - Functional programming is a lot about that.
[37:23] It's about all the things we don't have to think about
[37:27] so we can think about what's right in front of us.
[37:29] And that becomes really important
[37:31] as our applications get larger and more feature-rich.
[37:35] And they don't fit all in one person's head anymore.
[37:39] You have to be able to put most of the application
[37:41] out of your head and zoom in on what's right in front of you
[37:45] in order to solve these problems effectively.
[37:49] I hear from people who've gone from .NET to Ruby
[37:53] is that Ruby developers have a lot of discipline
[37:56] compared to Java and .NET programmers,
[37:58] that we, programming Ruby, impose discipline
[38:02] on our code.
[38:04] And we do that through idiomatic practices
[38:07] and just avoiding the sticky bits.
[38:10] And we can choose to follow the same functional principles
[38:15] that Haskell imposes on its developers.
[38:18] We can do that of our own choice.
[38:20] Ruby development is consensual.
[38:22] (audience laughing)
[38:25] So The Ruby community has taught the Java community
[38:28] a crapload of stuff about unit testing
[38:31] and how useful it is.
[38:32] Here's something the Java community can give back.
[38:35] If you have to overwrite methods
[38:36] or inject private states or in any way
[38:39] get around the simple stuff that you would do
[38:42] in production code in order to test an object,
[38:45] your object's wrong, your design is poor.
[38:49] Realize that nil is not data.
[38:53] So the problem with nil is it has 16 different meanings.
[38:57] It means false, it means crap, I screwed something up,
[39:00] it means not applicable.
[39:02] In a hash, it could mean key not found,
[39:04] or it could mean the key contains nil.
[39:08] And when it can mean 16 different things,
[39:10] it means nothing.
[39:15] - So when I was in college, the idea
[39:17] of functional programming was like this ivory tower,
[39:21] faux academic nonsense that was really full
[39:24] of mathematical notation and people
[39:26] puffing their chest, pretending they're smarter
[39:27] than everyone else.
[39:28] How most of us in this room learned functional programming
[39:31] is cause Matz thought that these were cool functions
[39:33] to throw on innumerable and wanted to teach them
[39:35] to people to be useful.
[39:37] And so I feel like Ruby was a great gateway drug
[39:40] to real, blue-collar functional programming
[39:43] and popularized in the way that academia had failed.
[39:48] - This is the only talk that we're gonna
[39:49] present today that wasn't presented
[39:50] at a Ruby-specific conference.
[39:51] But it was given by Jim Weirich,
[39:53] so we'll give it a pass.
[39:57] - Okay, so what does it mean?
[39:58] Connascence itself means let's talk
[39:59] about the common birth of two or more things
[40:01] at the same time and the production
[40:03] of two things that tend to grow together,
[40:05] that tend to stay the same.
[40:08] So connascence in software
[40:12] are those things that need to change together.
[40:17] So what is name connascence?
[40:19] Suppose you have a definition of a method here called foo,
[40:22] and then we call foo over here.
[40:24] This is connascence of name,
[40:26] because if I decide to change the name
[40:27] of my method foo, I obviously have to change
[40:31] the name of every place where foo is called.
[40:35] Variable where it's defined, and the title
[40:37] has to be there, and the address has to be there.
[40:40] So if I were to change the order
[40:42] of my parameters in this list,
[40:44] I would have to change the order of every place
[40:48] that was called to match the changing of order.
[40:53] Why is connascence important?
[40:55] Change is expensive.
[40:57] It's good software practice to reduce the coupling
[41:00] between your modules.
[41:03] And connascence is a way of talking
[41:05] about coupling in a particular way.
[41:09] One of these displays is exactly like the first one,
[41:12] displays all the methods available
[41:14] for the Fixnum class.
[41:16] The other one displays all the methods
[41:17] defined explicitly in the Fixnum
[41:20] but not in the ancestors of Fixnum.
[41:25] Which one is which?
[41:29] Okay, first one's all the way up.
[41:31] How do you remember that?
[41:32] Cause please tell me.
[41:33] (laughs) You just looked it up, okay.
[41:35] I did too, yeah.
[41:36] Since i just looked it up for this talk, I know.
[41:39] But I forget it every single time.
[41:41] This is connascence of meaning.
[41:43] We have assigned a particular meaning
[41:45] to the values true and false
[41:46] that is not evident from their usage right here.
[41:53] Actions, reduce the degree of connascence in your code,
[41:57] increase locality.
[41:58] And things that need to change together,
[42:00] put them in the same module.
[42:01] Bring them closer together so they can change
[42:03] together more easily.
[42:05] And don't repeat yourself is kind of
[42:07] an application of increasing locality.
[42:12] Single responsibility principle
[42:14] also moves in that direction.
[42:16] So it think these things are kind of based
[42:18] upon the locality idea in connascence.
[42:22] - So that's what coupling means.
[42:24] For me, that word just meant nothing until
[42:26] I saw that talk, and Jim explained coupling
[42:28] through the term connascence.
[42:31] It makes me really sad to even have to share
[42:34] that Jim passed away a few years ago.
[42:37] But he meant so much to the Ruby community
[42:41] from its heady XP days and from the year 2000 onward
[42:45] to kind of shepherding so many of us through
[42:47] how to build solid, awesome Ruby code
[42:51] that if you go to his last commit on GitHub,
[42:54] some of you might not know this,
[42:55] there's thousands of comments thanking Jim
[42:56] for his contributions.
[42:58] And somewhere in some GitHub.com template
[42:59] is an if-else conditional to print
[43:01] this thank you message.
[43:04] We recommend you go back and watch
[43:05] all of Jim's old talks.
[43:06] And if you do and you appreciate it,
[43:08] we encourage you to contribute to the Weirich Fund,
[43:10] to the scholarship program that's trying
[43:13] to keep Jim's memory alive and also help
[43:15] more people find the joys in the computer science
[43:18] that he did.
[43:21] So clearly, Ruby's a really thoughtful language.
[43:24] We spend a lot of time at conferences
[43:25] talking about ways that we can get better at our craft.
[43:30] - At RubyConf Charlotte in 2007,
[43:33] Marcel Molina gave a fantastic talk about beauty.
[43:38] - There's something deeper than just appearances
[43:42] that actually dictates what makes something beautiful
[43:45] versus not beautiful.
[43:51] The first topic that he brings up is proportion.
[43:55] The next piece is integrity.
[43:59] Third is clarity, and clarity is a simple concept.
[44:04] It's something is clear, and something is simple.
[44:08] That's a simple working definition
[44:11] for what makes something beautiful.
[44:12] Those three parts.
[44:14] Now, we're gonna apply that to a piece of software
[44:16] to see how this can actually relate
[44:18] to code that we write.
[44:22] Can choose one or two.
[44:24] They're intended to all work in concert.
[44:27] And they balance each other out.
[44:29] So they're each necessary, but none of them are sufficient.
[44:33] I don't know if he uses the word beauty anywhere
[44:36] in the entire book.
[44:39] But if you look at the information he gives you
[44:44] and you think about the three principles of beauty,
[44:47] almost every piece of information in that book
[44:50] is driving you towards fulfilling
[44:53] one or more of the three principles
[44:57] that go to our working definition of beauty.
[45:01] So he's setting out to write a book
[45:04] about how to write great software.
[45:06] And it turns out that all the software
[45:08] that you create following those principles
[45:12] is also, by this definition of beauty,
[45:15] beautiful software.
[45:19] Lucky for us, Ruby is optimized for beauty, big time.
[45:26] I'd like to finish just by thanking
[45:28] Matz and the Ruby core team
[45:30] for writing what I think is the most beautiful
[45:32] language I've ever used.
[45:35] So I'd like to thank Matz.
[45:36] Give him and applause.
[45:37] (applause)
[45:42] - So it's no secret, surrounding yourself
[45:45] with beautiful code will lead to happy developers.
[45:48] I think it also stands to reason
[45:49] that happy developers make more progress faster.
[45:52] Ask your manager, more progress will lead
[45:55] to more money.
[45:56] And so through the transitive property,
[45:58] this is not like hippy-dippy bullshit.
[46:01] Beautiful code leads to more money.
[46:03] There, I proved it.
[46:04] (audience laughing)
[46:05] So this is actually really valuable stuff.
[46:07] - In a interview with O'Reilly in 2001,
[46:10] Matz was asked the following.
[46:12] "Did you have a guiding philosophy
[46:13] "when designing Ruby?"
[46:15] He replied, "yes, it's called the principle
[46:17] "of least surprise.
[46:18] "I believe people want to express themselves
[46:20] "when they program.
[46:21] "They don't want to fight with the language."
[46:23] - First day at my first programming internship,
[46:25] the first piece of advice I got
[46:27] was that there's no such thing as a good surprise.
[46:29] And what the person was talking about
[46:31] was even with great tools,
[46:34] it's predictable tools that enable flow.
[46:36] And even a good surprise can break you out of it.
[46:39] - At Cascadia Ruby in 2012,
[46:42] Katrina Owen gave a fantastic talk
[46:44] about how refactoring brings joy.
[46:48] - Taken to coming into the office
[46:49] early in the morning and committing
[46:51] random acts of refactoring.
[46:54] Some people are calling this guilt-driven development.
[46:56] (audience laughing)
[46:58] But really it's not.
[47:00] Refactoring just makes me happy.
[47:04] I found this particular specimen
[47:06] in the dark recesses of that code base.
[47:09] It had no tests, and there was no documentation.
[47:15] Where do you even begin testing
[47:16] something like this?
[47:20] We don't really know what the inputs look like.
[47:24] We certainly don't know what the output looks like.
[47:27] We do know that it's in production
[47:29] and it appears to be working,
[47:30] because we haven't had any complaints
[47:31] from the customer about it.
[47:33] (audience laughing)
[47:37] The easiest way to discover inputs
[47:38] is to just send something, anything really,
[47:41] into the method, and then see what comes back out.
[47:46] We took a piece of undocumented, untested code,
[47:50] and with a bit of hand-waving,
[47:52] we got fake assertions to give us the inputs.
[47:56] The inputs gave us the outputs,
[47:58] and the outputs gave us the real assertions.
[48:03] Perfect? Of course not.
[48:05] Is it better?
[48:06] Hell yeah.
[48:09] We went from this to this in less than 30 steps.
[48:14] I started optimizing for happiness.
[48:18] I would specifically put something
[48:20] into its own class just so that I could load
[48:21] just that class and nothing else.
[48:24] The feedback loop you get when you have
[48:26] sub-second test suites for the thing
[48:28] that you're working on is unbelievable.
[48:31] It's a huge enabler for flow.
[48:37] - Along the same lines of the emotional layer
[48:39] of productivity with software,
[48:41] Kent Beck at RailsConf a couple years ago
[48:43] in Atlanta shared this.
[48:45] - Those emotions are valuable information.
[48:47] Emotions are noisy information,
[48:49] but they're valuable information.
[48:51] And that feeling of "I'm proud of this" means something.
[48:55] And that feeling like, "oh, I hope nobody
[48:56] "ever looks inside this file,"
[48:59] that also means something.
[49:01] (audience laughing)
[49:03] - Remember that email from Dave Thomas earlier?
[49:04] Yes, that's Dave Thomas.
[49:06] This is how he closed it.
[49:07] He said, "I'm grateful for the excitement
[49:08] "that surrounds Ruby, that keeps it fresh and growing.
[49:11] "I'm happy for the folks who found a home here.
[49:13] "Programming is difficult, and programmers deserve
[49:15] "to use the tools that they love."
[49:18] - So one of my favorite aspects of Ruby
[49:20] is the pursuit of joy and programmer happiness and delight.
[49:26] I'd love for you to look up Ruby Koans
[49:29] at some point soon.
[49:31] Work through those exercises.
[49:32] They're great.
[49:33] Start a Ruby Quiz club with some friends
[49:35] and play through some of the old example quizzes there.
[49:39] Go on Exorcism, go through the Ruby exercises
[49:41] so that you can go and comment
[49:42] and help other people who are trying to learn Ruby.
[49:45] We've only covered 12 talks.
[49:46] There's 2172 to go.
[49:47] So you got some homework for yourself.
[49:50] Would love, like, think about the date
[49:52] you started using Ruby.
[49:53] And then use Google advanced search
[49:54] and go look for some Ruby blog stuff.
[49:56] See what people were talking about
[49:58] in our community before you joined.
[50:00] And our message to you is we want you
[50:02] to go do something that makes you want to say, "wups!"
[50:06] Cause the last facet of Ruby's future
[50:07] is really gonna be determined by people
[50:09] like you, in this room.
[50:11] So yeah, we work for Test Double.
[50:12] We're an agency.
[50:13] We're way over time.
[50:15] We'd love for you to join the team, at that URL.
[50:18] Like I said, all these links are gonna be up
[50:19] at our blog in just a little bit here.
[50:22] And thank you so much for sitting through with us.
[50:24] (applause)

If you enjoy this video, let us know by twitter or e-mail! If you'd like to discuss it, open an issue on our feedback repo!