There's Nothing.new under the sun

Time An icon of a clock Publish Date
Person An icon of a human figure Authors
Josh Greenwood
Person An icon of a human figure Authors
Justin Searls
Transcript

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!

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
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
Whoa!
11:20
(audience laughing)
11:21
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
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
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
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
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
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
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
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
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)

Josh Greenwood

Person An icon of a human figure Status
Sleeper Agent
Hash An icon of a hash sign Code Name
Agent 0014

Justin Searls

Person An icon of a human figure Status
Double Agent
Hash An icon of a hash sign Code Name
Agent 002
Location An icon of a map marker Location
Orlando, FL