Ten Years of Rails Tutorials
Hartl, Michael
Come see how Rails has evolved over the years through the lens of introductory Rails tutorials. Marvel at Rails pre-REST, survive the merger with Merb, feel the joy & pain of the then-new asset pipeline, and watch testing techniques grow, evolve, and simplify. Leave with a deeper appreciation for where Rails came from and where it is today.
 Well, good morning everyone. How's everyone doing? Having a good time? All right. My name is Michael Hartle, and I am the author of the Ruby on Rails tutorial. How many people here have read some or all of the Rails tutorial? We've got a packed house. Awesome. Thanks for that. I'll send your check later to compensate you for filling it out here. So I'm here to talk about ten years of Rails tutorials. So what that means is we're going to look at the development of Rails itself through the lens of introductory tutorials. So the story begins when I was in graduate school at Caltech in Pasadena, California. So when I was at Caltech, I taught the physics core curriculum for five years and had a lot of success as a teacher. But I decided while I was there, I got interested in entrepreneurship. So as preparation for becoming an entrepreneur, I decided to learn how to make web applications. I figured that would be a useful skill to know. Little did I suspect at the time that my first successful company after two failed startups would be making a company to teach people web development. But those were primitive days, though. So I actually dug up a picture of what web application development looked like at that time. It was like the early 2000s. This picture here. So what you do is you kind of, you spread some HTML on your text editor and you like press it into the web browser and then send it back to the user. But seriously, it was really quite primitive. My first web development language was PHP. And stuff like this, like you would just echo out strings to the browser, like, as HTML. It was, you put in like Ross QL. It was really early, early days. So I learned PHP, built a couple of projects with that, and then I was looking for something a little more structured. And so I found this thing again. This is what things look like back then. This is something called Zope. I'm guessing that very few people here have heard of this. This is a framework written in Python, which is a lovely language, similar to Ruby in many ways. And Zope was good for making things like a content management system. But by this time, I was working on my own startup and I needed to build general purpose web applications. And so I really felt like there was something missing. Everything out there was working at the wrong level of abstraction. So PHP at the time, there weren't any real frameworks. There was just output strings. There was something like Zope, which was great if you were making a content management system, but otherwise, you know, kind of stuck. And it really seemed, it was obvious that there needed to be some way of making database-backed web applications that rendered HTML to the user. It took care of all the annoying details, things like sessions and cookies and redirects and that sort of stuff. So at the time, there really wasn't pretty much available. So I built my own kind of half-baked web framework in Python on top of Zope. And it worked for the startup I was doing. The company didn't work, but that's not because the technology failed. But because of this, because I had gone through the process of making my own web framework, which, like I said, totally half-baked, not suitable for public consumption, I was in a position to appreciate all of the problems that Rails was solving. So when Rails came out, when this 15-minute blog, a original little movie came out, I was ready for it. Like, I understood the problems that it was solving. I understood how difficult it was to put everything together, and I immediately appreciated that this was something special. It really was a revelation at the time. Now, it's easy to forget this. You look at some of the things that Rails does, and you think, yeah, like, that's just obvious, right? Like, that everyone does that. No, that's not obvious. A lot of the things that look obvious were done by Rails first, or was the first to popularize it. It looks obvious only because Rails was so successful in getting those design patterns out to the world. So at that point, it was pretty obvious that Rails was a good horse to bet on. And my first company had failed, so I was kind of had some free time to learn a new web framework. So I took a course given by this man, Dave Thomas and Mike Clark. So I had read a programming Ruby, which Dave wrote, and I took this course. It was really super compressed. Three days, you can't really learn web development in three days or even three weeks, maybe three months. But it gave a nice overview. And so after that, I was ready to read, at the time, it was the only Rails book, which was Agile Web Development with Rails, by Dave Thomas and David Heinemeyer Hansen. So in preparing this talk, I needed a copy of this book, and so I didn't have one lying around. I actually had a second edition, but this is the first edition, and I'd like to thank Dave Thomas for being gracious enough to answer my email and send me a PDF copy of this book. The PDF, though, did not have the cover, so I wanted to track down a cover, so I rolled into Amazon, where you can still buy a first edition, presumably as a collector's item. It's not very useful for the current state of Rails. But there is something else I want to draw your attention to. It's amazing and a little creepy. You purchased this item on December 5th, 2005. Amazon never forgets. So I read the only book available at the time, and then a couple years later, with a friend of mine from Caltech, I wrote my first Rails tutorial book, which maybe a couple of people in here have even heard of. It's called Railspace. This was a building a social networking website in Ruby on Rails. To give you a sense of how long ago this was, Railspace is a reference to Myspace. That was still a really a thing at that time. Now, this subtitle makes it sound like it's about building social networks, but this really was just a Ruby on Rails tutorial that used a social network as the sample application. In fact, the publisher at the time wanted to call this book Ruby on Rails tutorial, but I thought, no, that's just such a boring generic name for a Rails tutorial. Like, why would you do that? So it turned out I saved that title for myself later on. So what we're going to talk about in this first section of the talk is just how ahead of the curve Rails was. Like I said before, it's the kind of thing that's easy to forget just how ahead of its time Rails was, because Rails has pushed the whole industry as it's gone along. So starting right at the beginning, right with the new project, Rails new project name. Okay, it wasn't actually this, it was this. You just type Rails project name. It's changed a little bit. This was a big deal that you typed a command to the command line and automatically generated a full project skeleton. Like this was not normal. This was not something that people did, but it was amazing because you had this standard set of directories and files. It meant you had a place to start. And it also meant that if you looked at a project that someone else made, you had a way into it. You were familiar with the basic way it was put together. So of course Rails solved a bunch of the standard problems of web development that was not a standard thing to do at all. It just put it all together. One of the things it could do is it could talk to the database. So this is what a data center looked like in the early 2000s, I think. This might be the 1940s E-NiAC, but I'm not sure. Things have come a long way since then in any case. So you'd start off and you would create a table. This is a force of foreshadowing here. You could talk to the database. You could inherit at the time from Active Record Base. And in Ruby, you could interact with the database. You could persist data. You could pull it out. You could validate data. This is from Railspace. This is from like 2007. So already Rails was doing amazing things. Of course, you eventually need to put something out to the world. So you want to have your awesome website on the Internet. And you might even want to say your Kramer number broken image to visit our site. But that's a dynamically generated broken image. That's being pulled from a database somewhere. So Rails let you do this. It let you do things like user.screenname. Again, you can see how dated this is. This is back when Alonso Messenger was still a thing. So screen names were still a thing. I guess people still use it, but not as much as they did back then. So this is being pulled from a database and propagating all the way to the view and it's being generated dynamically by embedded Ruby. So having a full-strength programming language inside the views, like that was really unusual. So you could also render parcels. It's the kind of thing that Rails was really a pioneer in and being able to reuse pieces of HTML. You could also generate forms. This was amazing. This looks a little dated, but it's pretty close. And again, you could use something like a screen name in the text field to submit it, but if this were editing a user, this would be pulled from the database. It would be dynamically populated. So this was huge, to have this all this structured way of building up forms right from the beginning. Of course, you need something in between. You need something to talk to the database, to coordinate with the views. You need a controller in the middle. So this is what a controller looked like in Rails space. Again, like around circa 2007, Rails 1.2. User controller, not quite the same as we would say today. That's also a little foreshadowing. But look, you could register a user with an action. You could redirect. So this was amazing. You can see how I've gone through these three steps. We had the database interacting with the model. We had the HTML being dynamically rendered as a view. We got the controller right from the start. Rails had the model view controller architecture for organizing web applications. This was huge. To know where to put stuff, this was brand new for most people who encountered this. People would just write these horrible scripts with everything kind of mashed together. This gave us a nice way to structure web applications. So once you've made your app, though, you want to put it out there. You want to get it in front of an audience. And this was rough. The end of Rails space, my co-author and I just punted. Deployment was too hard. We said, all right, well, you can make a production database. And then you can run it locally with long-grill Rails. I remember that, but most of you probably don't. This is running on port 8000. That's local. It was too hard to deploy an app. So we said, all right, well, the best we can do is run your app locally in production. So it is a production environment. But if you really want to put it out there, you can do this, whatever that is. Really confusing. So this is a little loose thread that we'll be tying up later on in the talk. So it was amazing, but it was still a little raw in some ways. So at this point, I'd like to build a bridge from the early, early days and go through to where we are today, and then we'll compare and contrast the old and new ways of doing things. So for these examples, most of them will be drawn from my own series of books, starting with Rails space and then going through the Ruby on Rails tutorial. Originally, it was a Ruby on Rails 3 tutorial. It's been through four editions now. There will be a couple of examples from Agile Web Development with Rails as well. And specifically, we're going to look at the evolution of testing in the Rails tutorial or starting in Rails space. So this is what a test for login success looked like in 2007 or so. It's actually not that different, as we'll see. Now, I have to emphasize, again, this was a revelation. In my first company, I had spent so much time debugging forms by hand, making a change, like, all right, now I've got to test all these different code paths. It was just a nightmare. I was like, oh, there's something broken production. Great, let me fix it and deploy again. Being able to write a test that would just go through all of the things that you needed to test before deploying, that was incredible. Right at the beginning, we had a way of populating test database, in this case with fixtures. These are a couple of references to some Caltech figures I had mentioned before my co-author is also a Caltech alumnus, so Robert Millican, Arthur Amos Noise, a couple of the main people who got Caltech going back in the day. It was great. We could populate a database, run tests. Then the Rails tutorial came along, and I started kind of mixing and matching. One of the things that I used was something called Factory Girl, presumably named for a movie of the same name. So by the time the first edition of the Rails tutorial rolled around, I had a Factory user. I mean, you remember exactly what this did under the hood, but you could define a user and sort of populate it in the test. I've also got here a Describe block. I'm sure many of you recognize this as RSpec. So this was a change from my first foray into the Rails tutorial world. For the second edition, I added Cucumber, which was a way of writing these sort of plain text tests. And I think the dream was that maybe you could get the business people who understood the business requirements to write these tests, and then as a developer, you on the back end could do stuff like this. I don't know if it ever really worked out. It's really hard. They're pretty tightly coupled. I think fastening them apart is quite difficult. And so at this point, having gone through these different ways of testing, I realized some of the downsides, that they didn't always work as advertised. They tended to break when Rails upgraded to a new version, and having a third-party dependency made things quite brittle. And so I realized that I'd kind of gotten into this mode where I was just going with what was fashionable. People were excited about Cucumber, so let's make a Cucumber section in the Rails tutorial. So for the third and fourth editions, I went back to basics. I said, you know what? All of these fancy testing techniques are nice, and they have their place. But at the end of the day, what's really important is to have something more than nothing. Just having a test suite is such a huge win. I'm going to focus on the things that everyone needs to know. So I went back to the default stack. This is Railspace 2007 or so, and here's the latest edition of the most up-to-date version. This could actually be updated even a little more. There are some things here that are showing their age just a little bit, but you get the idea. And I also focused at this point on making integration tests. I felt like, and that was sort of a trend that people over the years realized that web applications are tightly coupled enough, that it's a good idea just to test everything at once. So I kind of went back to basics even to the point of going back and using fixtures. The main difference is instead of Caltech references, now there's a reference to the TV show Archer. Yeah, do you want Rails integration tests? Because this is how you get Rails integration tests. So now that we've seen where Rails has landed today in terms of just the testing, I want to go back and forth and show you how Rails has always been pushing the envelope and staying up-to-date with the latest practices in web development and often pushing them forward. So what we're going to do is look at some examples of kind of an old-timey way of doing things, and then like the sleek new Lamborghini way. So I showed this slide before. This is from agile web development with Rails. Rails 1.0. This isn't Ruby though, what language is this? Yeah, so this is raw SQL. Some people say SQL, either way, but SQL is the right way. So this is raw SQL, and so that's what you had to do back in the early days. You would create a MySQL database and you would run this. And so this was, it wasn't great. The models were amazing, being able to use ActiveRecord was amazing, but this was not great. And yet, very quickly, Rails added this amazing innovation, Migration. A standardized way of changing the database to migrating it up, migrating it back, and you could write these in pure Ruby. So as early as Rails 1.2, you could just do something like this. So this is already a Lamborghini. This is like 2007, amazing, but you could already do this. So this is what it would look like today, more or less. It's changed, it's polished up a little bit, but the core was there. And so instead of having to fiddle with the database yourself, you could just do, write DB migrate. This has changed a little bit. It's Rails DB migrate now, but pretty close. So something else Rails did that was, again, pushing things forward was the asset pipeline. So the picture of me, by the way, on a snow machine in Fairbanks, Alaska, that is the Trans Alaska pipeline running down the road there. So the asset pipeline gave us a way to move the things like images, JavaScript, style sheets out of what was called the public directory back in the day, like the old-timey way of doing things. And then we could bundle things up in the app assets directory. And this was really painful for me because this change happened right at, like, pretty soon after Rails 3.0. This is Rails 3.1. It was just like a minor version bump, and it changed all of the directory structure, and I had to kind of scramble to update the tutorial with a new chapter, and then the second edition came out in fairly short order. So this hit the Ruby on Rails 3.0 tutorial and kind of made parts of it obsolete right away, but you know how things go. You just got to deal with it. There was a real benefit, though, because what it meant is you could bundle everything up into something like the application CSS with a nice little hash that helped with the browser expiry. And so, again, we think, oh, yeah, this is easy. Like, everyone uses things like Webpack, like a piece of cake. This was new. This was not something that people did. This was Rails pushing things forward, bundling everything together in a way that made things really convenient and moved the whole industry forward. So there's something else that Rails has been able to keep up with, and this is a real benefit of using a framework, is security. Right? Security is incredibly hard, and if you use a framework that lots of people are using, you can be assured that it will have figured out a lot of these little edge cases that you're never going to run into on your own until it's too late. So I want to give you some examples of how Rails actually wasn't as secure as it could have been and how it has kept up with the best practices by making things secure by default. So, for example, this is the original register action from Railspace. User.NewParamsOfUser. Does this make anyone nervous? I'm so happy for you if this doesn't make you nervous. So what's happening here is we're passing the parameters from the browser, or from the user client, directly into the model. The problem with this is that if you have, say, an admin flag on the user model, where setting it equal to one makes the user an administrator, you could actually pass that flag. You couldn't do it through the web, but you could use a command line client like curl and issue a request and turn a user into an admin. This was a vulnerability known as mass assignment, and it affected a huge number of the early Rails apps. So nowadays what you would do is you would define a method called user.Params. So it's a private method down here at the bottom, and then you would permit certain attributes. So here, name, email, password, and password confirmation. In particular, note that admin is not on that list. So if someone runs a curl request that tries to set the admin flag to one, it will raise an error. Another example of this is, again, from Railspace 2007 or so, if you wanted to put in the user's screen name or their full name, you had to escape it out explicitly. This H is HTML escaped. So it's only one letter. Come on, how hard is it to type one letter, but this is really dangerous, and it's not what it meant. If you forgot to do this and someone put their name, this is like a little Bobby Tables in the XKTD. If your name were a malicious JavaScript, you would expose yourself to an attack called cross-site scripting. So in later versions of Rails, they added, well, there's no H there. That's because it's escaped by default. So it's safe by default. If you want to allow maybe some HTML tags, you can sanitize it. This has a whitelist of tags, or you can, if you're really, you know, feeling lucky, you can make it raw user name, but now that you're really getting what you deserve, you actually have to type raw to say, really just put this in literally what the user typed in. Probably a bad idea. So this brings me finally to maybe the biggest change, which was rest. I'm guessing many of you don't even remember this. So here's a baby anteater showing us how to rest. So rest stands for representational state transfer, and it is, it lies with the foundation of the web. And this is the kind of thing that was not well understood in web development, how to use this. So from the perspective of Rails, what this boiled down to was a set of seven standard actions. Index, show, new, edit, create, update, and destroy. So this is a real source of pain for me, because let me tell you, the rest revolution happened just as my co-author and I were finishing Rails Space. We were able to work in a, like a chapter that covered rest, but most of the book was not restful, as we say. So this, this hurt, and this is the way it goes. So let me show you the way this was. You may have noticed this, I'm sure some of you picked up on this. This is the register action. What's that? The old timey way. Here's an even older timey way. This is from agile web development with Rails, first edition. The login controller. What even is that? Well, rest taught us a way to think of our applications in terms of resources that were created, updated, read, or destroyed. And it's amazing how many different things in web development can be structured this way. Just a framework for developing a data model. Even for something like this that isn't usually backed by the database, you can say, well, what are we creating when someone logs in? Well, we're creating a session. So the current way to do this would be to say, let's have a sessions controller and then create that session. That's how you log in. So going back to the register example, this is now you do things. What are you doing when you're registering a user? You're creating a user. You can see this is the user controller, but we're thinking of these as users. It's a user's resource. The user's controller now, we have a create action. So it's the same as the session's controller in terms of the name. So we have this sort of consistency that gives us a way to anchor our development. Now, if you look at the latest version of this, at the end of the current edition of the Ruby Unreal tutorial, it's actually a Formula One, not even a Lamborghini. You've got something like this. User.send activation email. There's actually activations for users. So how can you do this? This is an introductory tutorial and you're sending email. How is that even possible? Part of it is that Rails gives you a way of composing emails and an interface to send them, but in order to actually send the email, you need some sort of third-party service. In this case, the Rails tutorial uses send grid. But this is an example of something that's happened in the world of web development as we've seen a real maturation of the ecosystem, including sending things like email. And this is the kind of thing that sometimes just happens as just a part of the natural development of technology. But in fact, in many cases, Rails has actually helped make this happen. It's not a separate evolution. The ecosystem has actually been driven forward and been affected by Rails. So for example, this is the end of Railspace. I showed this before in the context of how difficult it is to deploy things. Look at our recommendation for version control. Subversion or darks for version control. Why not Git? Git barely existed. It actually did technically exist, but I hadn't heard of it and I paid more attention to version control than almost anybody. And I didn't know about Git at this time. Git was not a thing, but it became a thing. And part of the reason it became a thing was because of GitHub. GitHub helped catalyze that process of driving Git adoption. So what is GitHub written in? Right, it's written in Rails. So to be able to make a site like GitHub with just a few people at the start, it couldn't have been done in like 2000. You would have needed a team of like a dozen people. But with the productivity boost given by Rails, GitHub could get off the ground. It was actually a side project for the founders. They had something else going on and it then started to take off. They said, yeah, maybe we should work on this side project. Another example that I like to use for my own projects is GitLab. The Rails tutorial actually recommends Bitbucket at this point because you can make private repositories for free, which is a good practice because then you're not exposing credentials accidentally. Web apps really should be in private repos. GitLab actually gives you public and private repos for free. So this was originally developed as something you would just install on your own server, sort of a GitHub style application. Now they have that and they have a hosted version as well. Again, GitLab is written in Rails. And so the kind of application this is requires a really mature ecosystem around it and Rails has been a key part of that. And so finally I'd like to show you this here, again, this slide from the end of Rails space where we just punted on deployment. Well, this was a major pain point, but the people in the Rails community pushed it forward. Companies like Engine Yard and Heroku. I watched this whole evolution. I actually went through the Y Combinator program in 2008 with the Heroku founders. They were the star of our class. So when I first met them, they had this IDE. It was kind of like Cloud9 now that part of Amazon Web Services, but it was too early for that, it turned out. And so they realized that the major pain point that was out there was deployment. And so they decided to make a command line client where you had to push with Git, which was that was completely unhinged in 2008 to require people to use Git. It was so new. GitHub had just gone out of private beta at that point. But because of this ecosystem, again, Heroku written in Rails by Rails developers pushing things forward to the point where before, we just punted at the end of a full book and said, this is too hard. Now it's literally in the first chapter of the Ruby Unreal tutorial. You don't even do anything before, at the end of the first chapter, Heroku create, Git puts Heroku. So now at this point, not only is it easy to get your work out in front of an audience, but everyone can be a rock star. So we've seen where we've gone and where we are. Let's think about where we're going, looking forward. Well, Rails has shown over and over again its ability to incorporate new ideas and to push things forward. So we can see just at this conference, some of the other talks that are going on, there's some exciting stuff happening in the JavaScript world, for example. And you can use React with Rails. You can use, like, Rails API, have Rails back end, the controller and the model, and then your front end can be in React. You can also use Rails with VJS or with Webpack. So Rails continues to play this central role where if you want to do authentication, authorization, handle all of the nitty-gritty details in the middle as your application progresses, if you want to swap out the front end, say, or if you want to use a different way of packaging up your assets, you can. So because of this demonstrated ability over and over again to be able to incorporate new ideas, push things forward, I think that the future of Rails is bright. And so with any luck, maybe we won't be talking about just ten years of Rails tutorials, maybe ten more years. Thanks. Thank you very much.
 Well, good morning everyone.  How's everyone doing?  Having a good time?  All right.  My name is Michael Hartle, and I am the author of the Ruby on Rails tutorial.  How many people here have read some or all of the Rails tutorial?  We've got a packed house.  Awesome.  Thanks for that.  I'll send your check later to compensate you for filling it out here.  So I'm here to talk about ten years of Rails tutorials.  So what that means is we're going to look at the development of Rails itself through the lens of introductory tutorials.  So the story begins when I was in graduate school at Caltech in Pasadena, California.  So when I was at Caltech, I taught the physics core curriculum for five years and had a lot of success as a teacher.  But I decided while I was there, I got interested in entrepreneurship.  So as preparation for becoming an entrepreneur, I decided to learn how to make web applications.  I figured that would be a useful skill to know.  Little did I suspect at the time that my first successful company after two failed startups would be making a company to teach people web development.  But those were primitive days, though.  So I actually dug up a picture of what web application development looked like at that time.  It was like the early 2000s.  This picture here.  So what you do is you kind of, you spread some HTML on your text editor and you like press it into the web browser and then send it back to the user.  But seriously, it was really quite primitive.  My first web development language was PHP.  And stuff like this, like you would just echo out strings to the browser, like, as HTML.  It was, you put in like Ross QL.  It was really early, early days.  So I learned PHP, built a couple of projects with that, and then I was looking for something a little more structured.  And so I found this thing again.  This is what things look like back then.  This is something called Zope.  I'm guessing that very few people here have heard of this.  This is a framework written in Python, which is a lovely language, similar to Ruby in many ways.  And Zope was good for making things like a content management system.  But by this time, I was working on my own startup and I needed to build general purpose web applications.  And so I really felt like there was something missing.  Everything out there was working at the wrong level of abstraction.  So PHP at the time, there weren't any real frameworks.  There was just output strings.  There was something like Zope, which was great if you were making a content management system, but otherwise, you know, kind of stuck.  And it really seemed, it was obvious that there needed to be some way of making database-backed web applications that rendered HTML to the user.  It took care of all the annoying details, things like sessions and cookies and redirects and that sort of stuff.  So at the time, there really wasn't pretty much available.  So I built my own kind of half-baked web framework in Python on top of Zope.  And it worked for the startup I was doing.  The company didn't work, but that's not because the technology failed.  But because of this, because I had gone through the process of making my own web framework, which, like I said, totally half-baked, not suitable for public consumption,  I was in a position to appreciate all of the problems that Rails was solving.  So when Rails came out, when this 15-minute blog, a original little movie came out, I was ready for it.  Like, I understood the problems that it was solving.  I understood how difficult it was to put everything together, and I immediately appreciated that this was something special.  It really was a revelation at the time.  Now, it's easy to forget this.  You look at some of the things that Rails does, and you think, yeah, like, that's just obvious, right?  Like, that everyone does that.  No, that's not obvious.  A lot of the things that look obvious were done by Rails first, or was the first to popularize it.  It looks obvious only because Rails was so successful in getting those design patterns out to the world.  So at that point, it was pretty obvious that Rails was a good horse to bet on.  And my first company had failed, so I was kind of had some free time to learn a new web framework.  So I took a course given by this man, Dave Thomas and Mike Clark.  So I had read a programming Ruby, which Dave wrote, and I took this course.  It was really super compressed.  Three days, you can't really learn web development in three days or even three weeks, maybe three months.  But it gave a nice overview.  And so after that, I was ready to read, at the time, it was the only Rails book,  which was Agile Web Development with Rails, by Dave Thomas and David Heinemeyer Hansen.  So in preparing this talk, I needed a copy of this book, and so I didn't have one lying around.  I actually had a second edition, but this is the first edition,  and I'd like to thank Dave Thomas for being gracious enough to answer my email and send me a PDF copy of this book.  The PDF, though, did not have the cover, so I wanted to track down a cover, so I rolled into Amazon,  where you can still buy a first edition, presumably as a collector's item.  It's not very useful for the current state of Rails.  But there is something else I want to draw your attention to.  It's amazing and a little creepy.  You purchased this item on December 5th, 2005.  Amazon never forgets.  So I read the only book available at the time, and then a couple years later, with a friend of mine from Caltech,  I wrote my first Rails tutorial book, which maybe a couple of people in here have even heard of.  It's called Railspace.  This was a building a social networking website in Ruby on Rails.  To give you a sense of how long ago this was, Railspace is a reference to Myspace.  That was still a really a thing at that time.  Now, this subtitle makes it sound like it's about building social networks,  but this really was just a Ruby on Rails tutorial that used a social network as the sample application.  In fact, the publisher at the time wanted to call this book Ruby on Rails tutorial,  but I thought, no, that's just such a boring generic name for a Rails tutorial.  Like, why would you do that?  So it turned out I saved that title for myself later on.  So what we're going to talk about in this first section of the talk is just how ahead of the curve Rails was.  Like I said before, it's the kind of thing that's easy to forget just how ahead of its time Rails was,  because Rails has pushed the whole industry as it's gone along.  So starting right at the beginning, right with the new project, Rails new project name.  Okay, it wasn't actually this, it was this.  You just type Rails project name.  It's changed a little bit.  This was a big deal that you typed a command to the command line and automatically generated a full project skeleton.  Like this was not normal.  This was not something that people did, but it was amazing because you had this standard set of directories and files.  It meant you had a place to start.  And it also meant that if you looked at a project that someone else made, you had a way into it.  You were familiar with the basic way it was put together.  So of course Rails solved a bunch of the standard problems of web development that was not a standard thing to do at all.  It just put it all together.  One of the things it could do is it could talk to the database.  So this is what a data center looked like in the early 2000s, I think.  This might be the 1940s E-NiAC, but I'm not sure.  Things have come a long way since then in any case.  So you'd start off and you would create a table.  This is a force of foreshadowing here.  You could talk to the database.  You could inherit at the time from Active Record Base.  And in Ruby, you could interact with the database.  You could persist data.  You could pull it out.  You could validate data.  This is from Railspace.  This is from like 2007.  So already Rails was doing amazing things.  Of course, you eventually need to put something out to the world.  So you want to have your awesome website on the Internet.  And you might even want to say your Kramer number broken image to visit our site.  But that's a dynamically generated broken image.  That's being pulled from a database somewhere.  So Rails let you do this.  It let you do things like user.screenname.  Again, you can see how dated this is.  This is back when Alonso Messenger was still a thing.  So screen names were still a thing.  I guess people still use it, but not as much as they did back then.  So this is being pulled from a database and propagating all the way to the view  and it's being generated dynamically by embedded Ruby.  So having a full-strength programming language inside the views,  like that was really unusual.  So you could also render parcels.  It's the kind of thing that Rails was really a pioneer in  and being able to reuse pieces of HTML.  You could also generate forms.  This was amazing.  This looks a little dated, but it's pretty close.  And again, you could use something like a screen name in the text field to submit it,  but if this were editing a user, this would be pulled from the database.  It would be dynamically populated.  So this was huge, to have this all this structured way of building up forms  right from the beginning.  Of course, you need something in between.  You need something to talk to the database, to coordinate with the views.  You need a controller in the middle.  So this is what a controller looked like in Rails space.  Again, like around circa 2007, Rails 1.2.  User controller, not quite the same as we would say today.  That's also a little foreshadowing.  But look, you could register a user with an action.  You could redirect.  So this was amazing.  You can see how I've gone through these three steps.  We had the database interacting with the model.  We had the HTML being dynamically rendered as a view.  We got the controller right from the start.  Rails had the model view controller architecture for organizing web applications.  This was huge.  To know where to put stuff, this was brand new for most people who encountered this.  People would just write these horrible scripts with everything kind of mashed together.  This gave us a nice way to structure web applications.  So once you've made your app, though, you want to put it out there.  You want to get it in front of an audience.  And this was rough.  The end of Rails space, my co-author and I just punted.  Deployment was too hard.  We said, all right, well, you can make a production database.  And then you can run it locally with long-grill Rails.  I remember that, but most of you probably don't.  This is running on port 8000.  That's local.  It was too hard to deploy an app.  So we said, all right, well, the best we can do is run your app locally in production.  So it is a production environment.  But if you really want to put it out there, you can do this, whatever that is.  Really confusing.  So this is a little loose thread that we'll be tying up later on in the talk.  So it was amazing, but it was still a little raw in some ways.  So at this point, I'd like to build a bridge from the early, early days  and go through to where we are today,  and then we'll compare and contrast the old and new ways of doing things.  So for these examples, most of them will be drawn from my own series of books,  starting with Rails space and then going through the Ruby on Rails tutorial.  Originally, it was a Ruby on Rails 3 tutorial.  It's been through four editions now.  There will be a couple of examples from Agile Web Development with Rails as well.  And specifically, we're going to look at the evolution of testing in the Rails tutorial  or starting in Rails space.  So this is what a test for login success looked like in 2007 or so.  It's actually not that different, as we'll see.  Now, I have to emphasize, again, this was a revelation.  In my first company, I had spent so much time debugging forms by hand,  making a change, like, all right, now I've got to test all these different code paths.  It was just a nightmare.  I was like, oh, there's something broken production.  Great, let me fix it and deploy again.  Being able to write a test that would just go through all of the things that you needed to test  before deploying, that was incredible.  Right at the beginning, we had a way of populating test database,  in this case with fixtures.  These are a couple of references to some Caltech figures I had mentioned  before my co-author is also a Caltech alumnus, so Robert Millican, Arthur Amos Noise,  a couple of the main people who got Caltech going back in the day.  It was great. We could populate a database, run tests.  Then the Rails tutorial came along, and I started kind of mixing and matching.  One of the things that I used was something called Factory Girl, presumably named for a movie of the same name.  So by the time the first edition of the Rails tutorial rolled around, I had a Factory user.  I mean, you remember exactly what this did under the hood, but you could define a user  and sort of populate it in the test.  I've also got here a Describe block.  I'm sure many of you recognize this as RSpec.  So this was a change from my first foray into the Rails tutorial world.  For the second edition, I added Cucumber, which was a way of writing these sort of plain text tests.  And I think the dream was that maybe you could get the business people who understood the business requirements  to write these tests, and then as a developer, you on the back end could do stuff like this.  I don't know if it ever really worked out.  It's really hard.  They're pretty tightly coupled.  I think fastening them apart is quite difficult.  And so at this point, having gone through these different ways of testing, I realized some of the downsides,  that they didn't always work as advertised.  They tended to break when Rails upgraded to a new version, and having a third-party dependency made things quite brittle.  And so I realized that I'd kind of gotten into this mode where I was just going with what was fashionable.  People were excited about Cucumber, so let's make a Cucumber section in the Rails tutorial.  So for the third and fourth editions, I went back to basics.  I said, you know what?  All of these fancy testing techniques are nice, and they have their place.  But at the end of the day, what's really important is to have something more than nothing.  Just having a test suite is such a huge win.  I'm going to focus on the things that everyone needs to know.  So I went back to the default stack.  This is Railspace 2007 or so, and here's the latest edition of the most up-to-date version.  This could actually be updated even a little more.  There are some things here that are showing their age just a little bit, but you get the idea.  And I also focused at this point on making integration tests.  I felt like, and that was sort of a trend that people over the years realized that web applications are tightly coupled enough,  that it's a good idea just to test everything at once.  So I kind of went back to basics even to the point of going back and using fixtures.  The main difference is instead of Caltech references, now there's a reference to the TV show Archer.  Yeah, do you want Rails integration tests?  Because this is how you get Rails integration tests.  So now that we've seen where Rails has landed today in terms of just the testing,  I want to go back and forth and show you how Rails has always been pushing the envelope  and staying up-to-date with the latest practices in web development and often pushing them forward.  So what we're going to do is look at some examples of kind of an old-timey way of doing things,  and then like the sleek new Lamborghini way.  So I showed this slide before. This is from agile web development with Rails.  Rails 1.0.  This isn't Ruby though, what language is this?  Yeah, so this is raw SQL. Some people say SQL, either way, but SQL is the right way.  So this is raw SQL, and so that's what you had to do back in the early days.  You would create a MySQL database and you would run this.  And so this was, it wasn't great.  The models were amazing, being able to use ActiveRecord was amazing, but this was not great.  And yet, very quickly, Rails added this amazing innovation, Migration.  A standardized way of changing the database to migrating it up, migrating it back,  and you could write these in pure Ruby.  So as early as Rails 1.2, you could just do something like this.  So this is already a Lamborghini. This is like 2007, amazing, but you could already do this.  So this is what it would look like today, more or less.  It's changed, it's polished up a little bit, but the core was there.  And so instead of having to fiddle with the database yourself, you could just do,  write DB migrate. This has changed a little bit.  It's Rails DB migrate now, but pretty close.  So something else Rails did that was, again, pushing things forward was the asset pipeline.  So the picture of me, by the way, on a snow machine in Fairbanks, Alaska,  that is the Trans Alaska pipeline running down the road there.  So the asset pipeline gave us a way to move the things like images, JavaScript,  style sheets out of what was called the public directory back in the day,  like the old-timey way of doing things.  And then we could bundle things up in the app assets directory.  And this was really painful for me because this change happened right at,  like, pretty soon after Rails 3.0. This is Rails 3.1.  It was just like a minor version bump, and it changed all of the directory structure,  and I had to kind of scramble to update the tutorial with a new chapter,  and then the second edition came out in fairly short order.  So this hit the Ruby on Rails 3.0 tutorial and kind of made parts of it obsolete right away,  but you know how things go.  You just got to deal with it.  There was a real benefit, though, because what it meant is you could bundle everything up  into something like the application CSS with a nice little hash that helped with the browser expiry.  And so, again, we think, oh, yeah, this is easy.  Like, everyone uses things like Webpack, like a piece of cake.  This was new. This was not something that people did.  This was Rails pushing things forward, bundling everything together in a way that made things really convenient  and moved the whole industry forward.  So there's something else that Rails has been able to keep up with,  and this is a real benefit of using a framework, is security.  Right? Security is incredibly hard, and if you use a framework that lots of people are using,  you can be assured that it will have figured out a lot of these little edge cases  that you're never going to run into on your own until it's too late.  So I want to give you some examples of how Rails actually wasn't as secure as it could have been  and how it has kept up with the best practices by making things secure by default.  So, for example, this is the original register action from Railspace.  User.NewParamsOfUser.  Does this make anyone nervous?  I'm so happy for you if this doesn't make you nervous.  So what's happening here is we're passing the parameters from the browser,  or from the user client, directly into the model.  The problem with this is that if you have, say, an admin flag on the user model,  where setting it equal to one makes the user an administrator,  you could actually pass that flag.  You couldn't do it through the web, but you could use a command line client like curl  and issue a request and turn a user into an admin.  This was a vulnerability known as mass assignment, and it affected a huge number of the early Rails apps.  So nowadays what you would do is you would define a method called user.Params.  So it's a private method down here at the bottom, and then you would permit certain attributes.  So here, name, email, password, and password confirmation.  In particular, note that admin is not on that list.  So if someone runs a curl request that tries to set the admin flag to one, it will raise an error.  Another example of this is, again, from Railspace 2007 or so,  if you wanted to put in the user's screen name or their full name,  you had to escape it out explicitly. This H is HTML escaped.  So it's only one letter.  Come on, how hard is it to type one letter, but this is really dangerous,  and it's not what it meant. If you forgot to do this and someone put their name,  this is like a little Bobby Tables in the XKTD.  If your name were a malicious JavaScript, you would expose yourself to an attack called cross-site scripting.  So in later versions of Rails, they added, well, there's no H there.  That's because it's escaped by default.  So it's safe by default.  If you want to allow maybe some HTML tags, you can sanitize it.  This has a whitelist of tags, or you can, if you're really, you know, feeling lucky,  you can make it raw user name, but now that you're really getting what you deserve,  you actually have to type raw to say, really just put this in literally what the user typed in.  Probably a bad idea.  So this brings me finally to maybe the biggest change, which was rest.  I'm guessing many of you don't even remember this.  So here's a baby anteater showing us how to rest.  So rest stands for representational state transfer, and it is, it lies with the foundation of the web.  And this is the kind of thing that was not well understood in web development, how to use this.  So from the perspective of Rails, what this boiled down to was a set of seven standard actions.  Index, show, new, edit, create, update, and destroy.  So this is a real source of pain for me, because let me tell you, the rest revolution happened  just as my co-author and I were finishing Rails Space.  We were able to work in a, like a chapter that covered rest, but most of the book was not restful, as we say.  So this, this hurt, and this is the way it goes.  So let me show you the way this was.  You may have noticed this, I'm sure some of you picked up on this.  This is the register action.  What's that?  The old timey way.  Here's an even older timey way.  This is from agile web development with Rails, first edition.  The login controller.  What even is that?  Well, rest taught us a way to think of our applications in terms of resources that were created,  updated, read, or destroyed.  And it's amazing how many different things in web development can be structured this way.  Just a framework for developing a data model.  Even for something like this that isn't usually backed by the database, you can say,  well, what are we creating when someone logs in?  Well, we're creating a session.  So the current way to do this would be to say, let's have a sessions controller and then create that session.  That's how you log in.  So going back to the register example, this is now you do things.  What are you doing when you're registering a user?  You're creating a user.  You can see this is the user controller, but we're thinking of these as users.  It's a user's resource.  The user's controller now, we have a create action.  So it's the same as the session's controller in terms of the name.  So we have this sort of consistency that gives us a way to anchor our development.  Now, if you look at the latest version of this, at the end of the current edition of the Ruby Unreal tutorial,  it's actually a Formula One, not even a Lamborghini.  You've got something like this.  User.send activation email.  There's actually activations for users.  So how can you do this?  This is an introductory tutorial and you're sending email.  How is that even possible?  Part of it is that Rails gives you a way of composing emails and an interface to send them,  but in order to actually send the email, you need some sort of third-party service.  In this case, the Rails tutorial uses send grid.  But this is an example of something that's happened in the world of web development  as we've seen a real maturation of the ecosystem, including sending things like email.  And this is the kind of thing that sometimes just happens as just a part of the natural development of technology.  But in fact, in many cases, Rails has actually helped make this happen.  It's not a separate evolution.  The ecosystem has actually been driven forward and been affected by Rails.  So for example, this is the end of Railspace.  I showed this before in the context of how difficult it is to deploy things.  Look at our recommendation for version control.  Subversion or darks for version control.  Why not Git?  Git barely existed.  It actually did technically exist, but I hadn't heard of it and I paid more attention to version control than almost anybody.  And I didn't know about Git at this time.  Git was not a thing, but it became a thing.  And part of the reason it became a thing was because of GitHub.  GitHub helped catalyze that process of driving Git adoption.  So what is GitHub written in?  Right, it's written in Rails.  So to be able to make a site like GitHub with just a few people at the start,  it couldn't have been done in like 2000.  You would have needed a team of like a dozen people.  But with the productivity boost given by Rails, GitHub could get off the ground.  It was actually a side project for the founders.  They had something else going on and it then started to take off.  They said, yeah, maybe we should work on this side project.  Another example that I like to use for my own projects is GitLab.  The Rails tutorial actually recommends Bitbucket at this point because you can make private repositories for free,  which is a good practice because then you're not exposing credentials accidentally.  Web apps really should be in private repos.  GitLab actually gives you public and private repos for free.  So this was originally developed as something you would just install on your own server, sort of a GitHub style application.  Now they have that and they have a hosted version as well.  Again, GitLab is written in Rails.  And so the kind of application this is requires a really mature ecosystem around it  and Rails has been a key part of that.  And so finally I'd like to show you this here, again, this slide from the end of Rails space where we just punted on deployment.  Well, this was a major pain point, but the people in the Rails community pushed it forward.  Companies like Engine Yard and Heroku.  I watched this whole evolution.  I actually went through the Y Combinator program in 2008 with the Heroku founders.  They were the star of our class.  So when I first met them, they had this IDE.  It was kind of like Cloud9 now that part of Amazon Web Services, but it was too early for that, it turned out.  And so they realized that the major pain point that was out there was deployment.  And so they decided to make a command line client where you had to push with Git,  which was that was completely unhinged in 2008 to require people to use Git.  It was so new.  GitHub had just gone out of private beta at that point.  But because of this ecosystem, again, Heroku written in Rails by Rails developers pushing things forward to the point where before,  we just punted at the end of a full book and said, this is too hard.  Now it's literally in the first chapter of the Ruby Unreal tutorial.  You don't even do anything before, at the end of the first chapter, Heroku create, Git puts Heroku.  So now at this point, not only is it easy to get your work out in front of an audience,  but everyone can be a rock star.  So we've seen where we've gone and where we are.  Let's think about where we're going, looking forward.  Well, Rails has shown over and over again its ability to incorporate new ideas and to push things forward.  So we can see just at this conference, some of the other talks that are going on,  there's some exciting stuff happening in the JavaScript world, for example.  And you can use React with Rails.  You can use, like, Rails API, have Rails back end, the controller and the model,  and then your front end can be in React.  You can also use Rails with VJS or with Webpack.  So Rails continues to play this central role where if you want to do authentication, authorization,  handle all of the nitty-gritty details in the middle as your application progresses,  if you want to swap out the front end, say, or if you want to use a different way of packaging up your assets, you can.  So because of this demonstrated ability over and over again to be able to incorporate new ideas, push things forward,  I think that the future of Rails is bright.  And so with any luck, maybe we won't be talking about just ten years of Rails tutorials, maybe ten more years.  Thanks.  Thank you very much.
RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_0_155.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_156_287.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_288_2399.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_2400_2807.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_2808_3995.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_3996_5579.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_5580_6947.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_6948_7487.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_7488_8279.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_8280_8891.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_8892_11783.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_11784_12095.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_12096_12863.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_12864_14999.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_15000_16499.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_16500_16787.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_16788_18179.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_18180_18659.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_18660_19583.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_19584_20675.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_20676_21743.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_21744_24311.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_24312_25127.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_25128_25271.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_25272_26231.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_26232_27755.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_27756_28199.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_28200_28823.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_28824_28991.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_28992_29291.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_29292_29771.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_29772_30467.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_30468_33179.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_33180_34691.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_34692_34931.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_34932_35099.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_35100_35411.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_35412_35531.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_35532_38663.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_38664_39299.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_39300_40067.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_40068_41063.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_41064_42179.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_42180_44399.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_44400_44915.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_44916_46055.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_46056_46247.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_46248_46715.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_46716_46859.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_46860_46907.png RailsConf_2018__Ten_Years_of_Rails_Tutorials_by_Michael_Hartl_46908_46976.png
Well, good morning everyone. How's everyone doing? Having a good time? All right. My name is Michael Hartle, and I am the author of the Ruby on Rails tutorial. How many people here have read some or all of the Rails tutorial? We've got a packed house. Awesome. Thanks for that. I'll send your check later to compensate you for filling it out here. So I'm here to talk about ten years of Rails tutorials. So what that means is we're going to look at the development of Rails itself through the lens of introductory tutorials. So the story begins when I was in graduate school at Caltech in Pasadena, California. So when I was at Caltech, I taught the physics core curriculum for five years and had a lot of success as a teacher. But I decided while I was there, I got interested in entrepreneurship. So as preparation for becoming an entrepreneur, I decided to learn how to make web applications. I figured that would be a useful skill to know. Little did I suspect at the time that my first successful company after two failed startups would be making a company to teach people web development. But those were primitive days, though. So I actually dug up a picture of what web application development looked like at that time. It was like the early 2000s. This picture here. So what you do is you kind of, you spread some HTML on your text editor and you like press it into the web browser and then send it back to the user. But seriously, it was really quite primitive. My first web development language was PHP. And stuff like this, like you would just echo out strings to the browser, like, as HTML. It was, you put in like Ross QL. It was really early, early days. So I learned PHP, built a couple of projects with that, and then I was looking for something a little more structured. And so I found this thing again. This is what things look like back then. This is something called Zope. I'm guessing that very few people here have heard of this. This is a framework written in Python, which is a lovely language, similar to Ruby in many ways. And Zope was good for making things like a content management system. But by this time, I was working on my own startup and I needed to build general purpose web applications. And so I really felt like there was something missing. Everything out there was working at the wrong level of abstraction. So PHP at the time, there weren't any real frameworks. There was just output strings. There was something like Zope, which was great if you were making a content management system, but otherwise, you know, kind of stuck. And it really seemed, it was obvious that there needed to be some way of making database-backed web applications that rendered HTML to the user. It took care of all the annoying details, things like sessions and cookies and redirects and that sort of stuff. So at the time, there really wasn't pretty much available. So I built my own kind of half-baked web framework in Python on top of Zope. And it worked for the startup I was doing. The company didn't work, but that's not because the technology failed. But because of this, because I had gone through the process of making my own web framework, which, like I said, totally half-baked, not suitable for public consumption, I was in a position to appreciate all of the problems that Rails was solving. So when Rails came out, when this 15-minute blog, a original little movie came out, I was ready for it. Like, I understood the problems that it was solving. I understood how difficult it was to put everything together, and I immediately appreciated that this was something special. It really was a revelation at the time. Now, it's easy to forget this. You look at some of the things that Rails does, and you think, yeah, like, that's just obvious, right? Like, that everyone does that. No, that's not obvious. A lot of the things that look obvious were done by Rails first, or was the first to popularize it. It looks obvious only because Rails was so successful in getting those design patterns out to the world. So at that point, it was pretty obvious that Rails was a good horse to bet on. And my first company had failed, so I was kind of had some free time to learn a new web framework. So I took a course given by this man, Dave Thomas and Mike Clark. So I had read a programming Ruby, which Dave wrote, and I took this course. It was really super compressed. Three days, you can't really learn web development in three days or even three weeks, maybe three months. But it gave a nice overview. And so after that, I was ready to read, at the time, it was the only Rails book, which was Agile Web Development with Rails, by Dave Thomas and David Heinemeyer Hansen. So in preparing this talk, I needed a copy of this book, and so I didn't have one lying around. I actually had a second edition, but this is the first edition, and I'd like to thank Dave Thomas for being gracious enough to answer my email and send me a PDF copy of this book. The PDF, though, did not have the cover, so I wanted to track down a cover, so I rolled into Amazon, where you can still buy a first edition, presumably as a collector's item. It's not very useful for the current state of Rails. But there is something else I want to draw your attention to. It's amazing and a little creepy. You purchased this item on December 5th, 2005. Amazon never forgets. So I read the only book available at the time, and then a couple years later, with a friend of mine from Caltech, I wrote my first Rails tutorial book, which maybe a couple of people in here have even heard of. It's called Railspace. This was a building a social networking website in Ruby on Rails. To give you a sense of how long ago this was, Railspace is a reference to Myspace. That was still a really a thing at that time. Now, this subtitle makes it sound like it's about building social networks, but this really was just a Ruby on Rails tutorial that used a social network as the sample application. In fact, the publisher at the time wanted to call this book Ruby on Rails tutorial, but I thought, no, that's just such a boring generic name for a Rails tutorial. Like, why would you do that? So it turned out I saved that title for myself later on. So what we're going to talk about in this first section of the talk is just how ahead of the curve Rails was. Like I said before, it's the kind of thing that's easy to forget just how ahead of its time Rails was, because Rails has pushed the whole industry as it's gone along. So starting right at the beginning, right with the new project, Rails new project name. Okay, it wasn't actually this, it was this. You just type Rails project name. It's changed a little bit. This was a big deal that you typed a command to the command line and automatically generated a full project skeleton. Like this was not normal. This was not something that people did, but it was amazing because you had this standard set of directories and files. It meant you had a place to start. And it also meant that if you looked at a project that someone else made, you had a way into it. You were familiar with the basic way it was put together. So of course Rails solved a bunch of the standard problems of web development that was not a standard thing to do at all. It just put it all together. One of the things it could do is it could talk to the database. So this is what a data center looked like in the early 2000s, I think. This might be the 1940s E-NiAC, but I'm not sure. Things have come a long way since then in any case. So you'd start off and you would create a table. This is a force of foreshadowing here. You could talk to the database. You could inherit at the time from Active Record Base. And in Ruby, you could interact with the database. You could persist data. You could pull it out. You could validate data. This is from Railspace. This is from like 2007. So already Rails was doing amazing things. Of course, you eventually need to put something out to the world. So you want to have your awesome website on the Internet. And you might even want to say your Kramer number broken image to visit our site. But that's a dynamically generated broken image. That's being pulled from a database somewhere. So Rails let you do this. It let you do things like user.screenname. Again, you can see how dated this is. This is back when Alonso Messenger was still a thing. So screen names were still a thing. I guess people still use it, but not as much as they did back then. So this is being pulled from a database and propagating all the way to the view and it's being generated dynamically by embedded Ruby. So having a full-strength programming language inside the views, like that was really unusual. So you could also render parcels. It's the kind of thing that Rails was really a pioneer in and being able to reuse pieces of HTML. You could also generate forms. This was amazing. This looks a little dated, but it's pretty close. And again, you could use something like a screen name in the text field to submit it, but if this were editing a user, this would be pulled from the database. It would be dynamically populated. So this was huge, to have this all this structured way of building up forms right from the beginning. Of course, you need something in between. You need something to talk to the database, to coordinate with the views. You need a controller in the middle. So this is what a controller looked like in Rails space. Again, like around circa 2007, Rails 1.2. User controller, not quite the same as we would say today. That's also a little foreshadowing. But look, you could register a user with an action. You could redirect. So this was amazing. You can see how I've gone through these three steps. We had the database interacting with the model. We had the HTML being dynamically rendered as a view. We got the controller right from the start. Rails had the model view controller architecture for organizing web applications. This was huge. To know where to put stuff, this was brand new for most people who encountered this. People would just write these horrible scripts with everything kind of mashed together. This gave us a nice way to structure web applications. So once you've made your app, though, you want to put it out there. You want to get it in front of an audience. And this was rough. The end of Rails space, my co-author and I just punted. Deployment was too hard. We said, all right, well, you can make a production database. And then you can run it locally with long-grill Rails. I remember that, but most of you probably don't. This is running on port 8000. That's local. It was too hard to deploy an app. So we said, all right, well, the best we can do is run your app locally in production. So it is a production environment. But if you really want to put it out there, you can do this, whatever that is. Really confusing. So this is a little loose thread that we'll be tying up later on in the talk. So it was amazing, but it was still a little raw in some ways. So at this point, I'd like to build a bridge from the early, early days and go through to where we are today, and then we'll compare and contrast the old and new ways of doing things. So for these examples, most of them will be drawn from my own series of books, starting with Rails space and then going through the Ruby on Rails tutorial. Originally, it was a Ruby on Rails 3 tutorial. It's been through four editions now. There will be a couple of examples from Agile Web Development with Rails as well. And specifically, we're going to look at the evolution of testing in the Rails tutorial or starting in Rails space. So this is what a test for login success looked like in 2007 or so. It's actually not that different, as we'll see. Now, I have to emphasize, again, this was a revelation. In my first company, I had spent so much time debugging forms by hand, making a change, like, all right, now I've got to test all these different code paths. It was just a nightmare. I was like, oh, there's something broken production. Great, let me fix it and deploy again. Being able to write a test that would just go through all of the things that you needed to test before deploying, that was incredible. Right at the beginning, we had a way of populating test database, in this case with fixtures. These are a couple of references to some Caltech figures I had mentioned before my co-author is also a Caltech alumnus, so Robert Millican, Arthur Amos Noise, a couple of the main people who got Caltech going back in the day. It was great. We could populate a database, run tests. Then the Rails tutorial came along, and I started kind of mixing and matching. One of the things that I used was something called Factory Girl, presumably named for a movie of the same name. So by the time the first edition of the Rails tutorial rolled around, I had a Factory user. I mean, you remember exactly what this did under the hood, but you could define a user and sort of populate it in the test. I've also got here a Describe block. I'm sure many of you recognize this as RSpec. So this was a change from my first foray into the Rails tutorial world. For the second edition, I added Cucumber, which was a way of writing these sort of plain text tests. And I think the dream was that maybe you could get the business people who understood the business requirements to write these tests, and then as a developer, you on the back end could do stuff like this. I don't know if it ever really worked out. It's really hard. They're pretty tightly coupled. I think fastening them apart is quite difficult. And so at this point, having gone through these different ways of testing, I realized some of the downsides, that they didn't always work as advertised. They tended to break when Rails upgraded to a new version, and having a third-party dependency made things quite brittle. And so I realized that I'd kind of gotten into this mode where I was just going with what was fashionable. People were excited about Cucumber, so let's make a Cucumber section in the Rails tutorial. So for the third and fourth editions, I went back to basics. I said, you know what? All of these fancy testing techniques are nice, and they have their place. But at the end of the day, what's really important is to have something more than nothing. Just having a test suite is such a huge win. I'm going to focus on the things that everyone needs to know. So I went back to the default stack. This is Railspace 2007 or so, and here's the latest edition of the most up-to-date version. This could actually be updated even a little more. There are some things here that are showing their age just a little bit, but you get the idea. And I also focused at this point on making integration tests. I felt like, and that was sort of a trend that people over the years realized that web applications are tightly coupled enough, that it's a good idea just to test everything at once. So I kind of went back to basics even to the point of going back and using fixtures. The main difference is instead of Caltech references, now there's a reference to the TV show Archer. Yeah, do you want Rails integration tests? Because this is how you get Rails integration tests. So now that we've seen where Rails has landed today in terms of just the testing, I want to go back and forth and show you how Rails has always been pushing the envelope and staying up-to-date with the latest practices in web development and often pushing them forward. So what we're going to do is look at some examples of kind of an old-timey way of doing things, and then like the sleek new Lamborghini way. So I showed this slide before. This is from agile web development with Rails. Rails 1.0. This isn't Ruby though, what language is this? Yeah, so this is raw SQL. Some people say SQL, either way, but SQL is the right way. So this is raw SQL, and so that's what you had to do back in the early days. You would create a MySQL database and you would run this. And so this was, it wasn't great. The models were amazing, being able to use ActiveRecord was amazing, but this was not great. And yet, very quickly, Rails added this amazing innovation, Migration. A standardized way of changing the database to migrating it up, migrating it back, and you could write these in pure Ruby. So as early as Rails 1.2, you could just do something like this. So this is already a Lamborghini. This is like 2007, amazing, but you could already do this. So this is what it would look like today, more or less. It's changed, it's polished up a little bit, but the core was there. And so instead of having to fiddle with the database yourself, you could just do, write DB migrate. This has changed a little bit. It's Rails DB migrate now, but pretty close. So something else Rails did that was, again, pushing things forward was the asset pipeline. So the picture of me, by the way, on a snow machine in Fairbanks, Alaska, that is the Trans Alaska pipeline running down the road there. So the asset pipeline gave us a way to move the things like images, JavaScript, style sheets out of what was called the public directory back in the day, like the old-timey way of doing things. And then we could bundle things up in the app assets directory. And this was really painful for me because this change happened right at, like, pretty soon after Rails 3.0. This is Rails 3.1. It was just like a minor version bump, and it changed all of the directory structure, and I had to kind of scramble to update the tutorial with a new chapter, and then the second edition came out in fairly short order. So this hit the Ruby on Rails 3.0 tutorial and kind of made parts of it obsolete right away, but you know how things go. You just got to deal with it. There was a real benefit, though, because what it meant is you could bundle everything up into something like the application CSS with a nice little hash that helped with the browser expiry. And so, again, we think, oh, yeah, this is easy. Like, everyone uses things like Webpack, like a piece of cake. This was new. This was not something that people did. This was Rails pushing things forward, bundling everything together in a way that made things really convenient and moved the whole industry forward. So there's something else that Rails has been able to keep up with, and this is a real benefit of using a framework, is security. Right? Security is incredibly hard, and if you use a framework that lots of people are using, you can be assured that it will have figured out a lot of these little edge cases that you're never going to run into on your own until it's too late. So I want to give you some examples of how Rails actually wasn't as secure as it could have been and how it has kept up with the best practices by making things secure by default. So, for example, this is the original register action from Railspace. User.NewParamsOfUser. Does this make anyone nervous? I'm so happy for you if this doesn't make you nervous. So what's happening here is we're passing the parameters from the browser, or from the user client, directly into the model. The problem with this is that if you have, say, an admin flag on the user model, where setting it equal to one makes the user an administrator, you could actually pass that flag. You couldn't do it through the web, but you could use a command line client like curl and issue a request and turn a user into an admin. This was a vulnerability known as mass assignment, and it affected a huge number of the early Rails apps. So nowadays what you would do is you would define a method called user.Params. So it's a private method down here at the bottom, and then you would permit certain attributes. So here, name, email, password, and password confirmation. In particular, note that admin is not on that list. So if someone runs a curl request that tries to set the admin flag to one, it will raise an error. Another example of this is, again, from Railspace 2007 or so, if you wanted to put in the user's screen name or their full name, you had to escape it out explicitly. This H is HTML escaped. So it's only one letter. Come on, how hard is it to type one letter, but this is really dangerous, and it's not what it meant. If you forgot to do this and someone put their name, this is like a little Bobby Tables in the XKTD. If your name were a malicious JavaScript, you would expose yourself to an attack called cross-site scripting. So in later versions of Rails, they added, well, there's no H there. That's because it's escaped by default. So it's safe by default. If you want to allow maybe some HTML tags, you can sanitize it. This has a whitelist of tags, or you can, if you're really, you know, feeling lucky, you can make it raw user name, but now that you're really getting what you deserve, you actually have to type raw to say, really just put this in literally what the user typed in. Probably a bad idea. So this brings me finally to maybe the biggest change, which was rest. I'm guessing many of you don't even remember this. So here's a baby anteater showing us how to rest. So rest stands for representational state transfer, and it is, it lies with the foundation of the web. And this is the kind of thing that was not well understood in web development, how to use this. So from the perspective of Rails, what this boiled down to was a set of seven standard actions. Index, show, new, edit, create, update, and destroy. So this is a real source of pain for me, because let me tell you, the rest revolution happened just as my co-author and I were finishing Rails Space. We were able to work in a, like a chapter that covered rest, but most of the book was not restful, as we say. So this, this hurt, and this is the way it goes. So let me show you the way this was. You may have noticed this, I'm sure some of you picked up on this. This is the register action. What's that? The old timey way. Here's an even older timey way. This is from agile web development with Rails, first edition. The login controller. What even is that? Well, rest taught us a way to think of our applications in terms of resources that were created, updated, read, or destroyed. And it's amazing how many different things in web development can be structured this way. Just a framework for developing a data model. Even for something like this that isn't usually backed by the database, you can say, well, what are we creating when someone logs in? Well, we're creating a session. So the current way to do this would be to say, let's have a sessions controller and then create that session. That's how you log in. So going back to the register example, this is now you do things. What are you doing when you're registering a user? You're creating a user. You can see this is the user controller, but we're thinking of these as users. It's a user's resource. The user's controller now, we have a create action. So it's the same as the session's controller in terms of the name. So we have this sort of consistency that gives us a way to anchor our development. Now, if you look at the latest version of this, at the end of the current edition of the Ruby Unreal tutorial, it's actually a Formula One, not even a Lamborghini. You've got something like this. User.send activation email. There's actually activations for users. So how can you do this? This is an introductory tutorial and you're sending email. How is that even possible? Part of it is that Rails gives you a way of composing emails and an interface to send them, but in order to actually send the email, you need some sort of third-party service. In this case, the Rails tutorial uses send grid. But this is an example of something that's happened in the world of web development as we've seen a real maturation of the ecosystem, including sending things like email. And this is the kind of thing that sometimes just happens as just a part of the natural development of technology. But in fact, in many cases, Rails has actually helped make this happen. It's not a separate evolution. The ecosystem has actually been driven forward and been affected by Rails. So for example, this is the end of Railspace. I showed this before in the context of how difficult it is to deploy things. Look at our recommendation for version control. Subversion or darks for version control. Why not Git? Git barely existed. It actually did technically exist, but I hadn't heard of it and I paid more attention to version control than almost anybody. And I didn't know about Git at this time. Git was not a thing, but it became a thing. And part of the reason it became a thing was because of GitHub. GitHub helped catalyze that process of driving Git adoption. So what is GitHub written in? Right, it's written in Rails. So to be able to make a site like GitHub with just a few people at the start, it couldn't have been done in like 2000. You would have needed a team of like a dozen people. But with the productivity boost given by Rails, GitHub could get off the ground. It was actually a side project for the founders. They had something else going on and it then started to take off. They said, yeah, maybe we should work on this side project. Another example that I like to use for my own projects is GitLab. The Rails tutorial actually recommends Bitbucket at this point because you can make private repositories for free, which is a good practice because then you're not exposing credentials accidentally. Web apps really should be in private repos. GitLab actually gives you public and private repos for free. So this was originally developed as something you would just install on your own server, sort of a GitHub style application. Now they have that and they have a hosted version as well. Again, GitLab is written in Rails. And so the kind of application this is requires a really mature ecosystem around it and Rails has been a key part of that. And so finally I'd like to show you this here, again, this slide from the end of Rails space where we just punted on deployment. Well, this was a major pain point, but the people in the Rails community pushed it forward. Companies like Engine Yard and Heroku. I watched this whole evolution. I actually went through the Y Combinator program in 2008 with the Heroku founders. They were the star of our class. So when I first met them, they had this IDE. It was kind of like Cloud9 now that part of Amazon Web Services, but it was too early for that, it turned out. And so they realized that the major pain point that was out there was deployment. And so they decided to make a command line client where you had to push with Git, which was that was completely unhinged in 2008 to require people to use Git. It was so new. GitHub had just gone out of private beta at that point. But because of this ecosystem, again, Heroku written in Rails by Rails developers pushing things forward to the point where before, we just punted at the end of a full book and said, this is too hard. Now it's literally in the first chapter of the Ruby Unreal tutorial. You don't even do anything before, at the end of the first chapter, Heroku create, Git puts Heroku. So now at this point, not only is it easy to get your work out in front of an audience, but everyone can be a rock star. So we've seen where we've gone and where we are. Let's think about where we're going, looking forward. Well, Rails has shown over and over again its ability to incorporate new ideas and to push things forward. So we can see just at this conference, some of the other talks that are going on, there's some exciting stuff happening in the JavaScript world, for example. And you can use React with Rails. You can use, like, Rails API, have Rails back end, the controller and the model, and then your front end can be in React. You can also use Rails with VJS or with Webpack. So Rails continues to play this central role where if you want to do authentication, authorization, handle all of the nitty-gritty details in the middle as your application progresses, if you want to swap out the front end, say, or if you want to use a different way of packaging up your assets, you can. So because of this demonstrated ability over and over again to be able to incorporate new ideas, push things forward, I think that the future of Rails is bright. And so with any luck, maybe we won't be talking about just ten years of Rails tutorials, maybe ten more years. Thanks. Thank you very much.
through the lens of introductory tutorials. So when Rails came out, when this 15-minute blog, a was amazing. You can see how I've gone through what? All of these fancy testing techniques are over the years realized that web applications are we've seen where Rails has landed today in terms pushing things forward was the asset pipeline. So and it is, it lies with the foundation of the