 Oh, 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. And how many people here have read somewhere all of the Rails tutorial? All right, we 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 10 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 spread some HTML on your text editor and you press it into the web browser and then send it back to the user. But seriously, it was really quite primitive. But my first web development language was PHP. And stuff like this, you would just echo out strings to the browser as HTML. It was, you put in RossQL. 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 the 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 to 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, original little movie came out, I was ready for it. 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. 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, that's just obvious, right? 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. 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 wanna 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 Rails Space. This was a building a social networking website in Ruby on Rails. To give you a sense of how long ago this was, Rails Space 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. And 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 gonna 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 that 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 typed Rails project name. It's changed a little bit. But 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 eniac, 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 foreshadowing here. But 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. Right? That's being pulled from a database somewhere. So Rails let you do this. It let you do things like at user.screenname. Again, you can see how dated this is. This is back when AOL Instant 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 is being generated dynamically by embedded Ruby. So having a full-strength programming language inside the views, that was really unusual. So you could also render parcels is the kind of thing that Rails was really a pioneer in 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. And 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. And here we've got the controller. So 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. So 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, right? 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 because deployment was too hard. We said, all right, well, you know, you can make a production database. And then you can run it locally with mongrel Rails. I remember that, but most of you probably don't. This is running on port 8,000. 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, as Ruby on Rails three tutorial, it's been through four editions. Now, there'll 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 was also a Caltech alumnus, so Robert Millican, Arthur Amos Noise, couple of the main people who got Caltech going back in the day. But 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 described 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 from 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. Like 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. Having a test suite is such a huge win. I'm gonna 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, 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 wanna go back and forth and show you how Rails has always been pushing the envelope and staying up-to-date with the latest practices and web development and often pushing them forward. So what we're gonna 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? 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, like 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 is 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, 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 a database yourself, you could just do rake 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, back in 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 pretty soon after Rails 3.0. This is Rails 3.1. 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 a 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 and the library, 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. 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 gonna run into on your own until it's too late. So I wanna 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.newparams of user. 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 escape. So it's only one letter. Come on, how hard is it to type one letter but this is really dangerous because it meant if you forgot to do this and someone put, their name is, 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 white list of tags. Or you can, if you're really feeling lucky, you can make it raw username 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 the, maybe the biggest change and 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 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 chapter that covered rest but most of the book was not restful, as we say. So 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, or updated, read, or destroyed. And it's amazing how many different things in web development can be structured this way. It gets 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. So 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 in 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.SendActivationEmail. There's actually activations for users. So how can you do, this is an introductory tutorial and you're sending email? How is that even possible? Well 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 SendGrid 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 Rails space. 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. 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 couldn't have been done in 2000. You would have needed a team of 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. I 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. 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 on Rails tutorial. You don't even do anything before, like at the end of the first chapter, Heroku create, Git put 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. It's 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 a Rails backend, the controller and the model and then your front end can be in React. You can also use Rails with Vue.js or with Webpack. So Rails continues to play this central role where if you wanna do authentication, authorization, handle all of the nitty gritty details in the middle as your application progresses, if you wanna swap out the front end, say, or if you wanna 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 10 years of Rails tutorials, maybe 10 more years. Thanks. Thank you very much.