Rails 5.1: Awesome Features and Breaking Changes
Baccigalupo, Claudio
Each minor release of Rails brings shiny new features and mild headaches for developers required to upgrade their applications and gems. Rails 5.1 will support Yarn and modern Javascript transpilers, remove jQuery from the default stack, integrate system testing and a concurrent test runner, introduce a new helper to create forms, provide encrypted secrets and more. In this talk, I will cover the improvements brought by Rails 5.1, explain the Core team’s motivations behind each feature, and illustrate the upgrade process to smoothly transition gems and apps from Rails 5.0 to Rails 5.1.
 Music My name is Fabio and today I'm going to talk to you about Rails 5.1, which is the latest release of the framework that we all love and enjoy. And the slides are available online and you might want to go there simply because there are links to the pull request that I'm going to talk about. So I only have 40 minutes. I can't go into details, but I invite you to go there and see at the commits at the discussion and hopefully get involved you with open source. To give you a little bit of context, 5.1 is going to be released any minute now, any day now. But just to give you an idea, when 5.0 was released, that was the result of 18 months of work and about 10,000 commits, about 1,000 committers. So with 5.1, you can think of it as kind of half of it, nine months of work, about 4,000 commits. I did this just with the git command and if you actually go and look at the git diff, you're going to see a lot of lines that have changed in the code base. And one of the reasons is that the Rails team is now using Rubikop for styling. So you're going to see many things like spaces, single quotes, double quotes, but that is not really going to affect you as users of Rails. So that is what I'm going to talk about today. If you use Rails, how is this new version going to affect you? And so what I'm going to talk about is breaking changes, then active record, active support, action view, real ties, and action pack. And so the last disclaimer before starting is that I have cats in this talk, so I'm going to start with the first one. Okay, breaking changes. Okay, breaking changes. Really, I have upgraded my apps to 5.1 and I haven't really encountered many that have affected me. I found some in the code that I'm going to talk about, but they are not that big. I'm going to start with the first one, which is the engine that reads your ERB files under the hood has changed from a Ruby to a Ruby. And the difference is not just an S at the end, it's also that a Ruby was now really being maintained since 2011, and a Ruby has a simpler internals and a smaller memory footprint. Now, if all you're doing in your app is just having ERB files, this is not going to affect you at all because the result is the same. This is only going to affect you if you actually are explicitly calling a Ruby in your code. For instance, if you have a jam, like Hamel or something that touches action view, then you might want to look at this. Otherwise, it just a benefit for you. It's going to be faster. The next one is when you set or skip callbacks, you can add conditions. You can say set if, skip if. And these conditions, you can pass them as strings. And let me show you what it means. I tried to write an example here if you have a post in your database, and then before you save this post, if it doesn't have the title, so unless the title is present, you want to set no title, that unless you could pass a string in 5.0. Same with if. Now, if this feels weird, it did feel weird to me. It's because there are alternatives to do this. So in 5.1, you're not going to be able to use a string anymore. But you can still, like, use a proc. You can still use a symbol. So if you're using strings for those conditions, then you might want to change to this new syntax. Still talking about breaking changes. This affects your config routes. When you set your routes, you're also going to use strings. You're going to say get dashboard index to home, things like that. So in this string, there are actually a couple of special symbols that you can use in your routes. You can do get and then this column controller was less colon action was less colon ID. So this kind of syntax was valid until race five. And these are wild cards. So if you have that in your routes, you're basically saying match any controller with any action or any ID. This is really powerful, but also it was the cause of a couple of security issues that have already been fixed in previous version of rails. So this decision was made so that going forward, this syntax would not be acceptable anymore. Instead, if you have many controllers or actions, you might want to whitelist them explicitly, which I also think makes for better and cleaner code. That's that's what I have so far for breaking changes. I'm not claiming these are all of them and I invite you to go and look at the changelog of the libraries. But I think it just gives you an idea about the fact that it's probably not going to be hard for you to upgrade to race 5.1. And so now we can start looking at the feature what has been added or improved and what can benefit your everyday work. Let's start with active record. Primary keys in your database, they used to be integers and now they can be big in or big serial if you impose grass. So you basically have 64 bit. So if you have, if you need to reference many records in database now, this is the default. You just have big in as your primary keys. This can be useful. And still talking about databases. This is only for my SQL or equivalent Maria DB. There is no support for virtual columns. I also, I'm going to show an example for this. Let's say you have a user stable every user has a name. Now every user, you can also say has an upper name which is just the uppercase version of the name. My SQL lets you do that with this upper name in SQL. So basically SQL has this virtual column, which is not like duplicate to just calculating the uppercase version. And now you can reference this column in your migration by writing playing Ruby, you just do to the virtual upper name. And it has even more features. Let's say you have another virtual column, which is name length, which is the number of characters of the name. You can tell my SQL to store this column and also to index by this column. So if you want to display your users sorted by the number of characters, you know, my SQL can do all of this. And this is all the code you need. And what is good about this is that you don't have to write your structure dot SQL, you can just write Ruby, which I guess we all prefer. Still talking about database. If you have to deal with many, many records like thousands of records. Active record provides methods to do this like find each or in batches. So if you wanted to iterate 5000 posts, you want to do maybe find each. And this works. There was just one gotcha that in 5.0. If you wanted to use the limit method, it wasn't really working. If you had to write post limit 500.pn each, you would actually get a warning saying scoped order and limit are ignored. And so the query would just fetch 1000 because that's the default in 5.1. The limit method is now supported. So that's good. Okay. I think I'm going a little fast on this initial new features. It's because maybe you've not heard about them. And hopefully I'm getting you curious about going to see everything that has changed. So bear with me and we're going to get to the end where you're probably going to see the features that have made the news or that other presenters are talking about here. But let's continue with active support. There is no support for Unicode nine. And here's an example of what this entails. Well, the value of the constant Unicode version is now nine and not eight. And as an example, let's say you have a string and this string has just a single emoji. This emoji is called a family with two mothers, one daughter and one son. This is one character. It's one emoji. But in 5.0, if you had asked for the length of this string, you would have gotten four. If you had asked to reverse this string, the family would have been split into four characters, which is probably not what you wanted. And so now in 5.1, there is full support for Unicode nine and families are not going to be separated anymore. Active support duration has two methods called since and until. And now they have aliases after and before. So it's easy to understand with an example. If in your code, you're writing two weeks since Christmas Day. Now you can say two weeks after Christmas Day. It's the same thing, but it might sound more natural and English. Five days until Christmas Day, you now have the option to say five days before Christmas Day, maybe in your test. This is something that you like better. Now you have the option. Let's get to one of the bigger request. There's a new method in module called delegate miss into. I think this is going to be very powerful for people who use the delegator pattern. So if you have a class with a bunch of methods, and then you have another class that wraps the first one, basically it's calling all the methods of the first one except couple. And this can help you. Let me show you how. I made another example here. Imagine have an order active record in order in your database so users can create orders, save order, destroy order. So that's just an active record base. And then you have another class called order completion that is delegating all the methods to the order. So it's doing everything that the order does except for create when an order completion is created. It's also sending a notification. This is a pattern that you can do in Rails and a way to do this it's using the delegate method which already existed. The problem with the delegate method is that you have to list all the methods that you want to delegate. So it might not be your first choice. Another way to do this is to use Ruby's metaprogramming methods. You can find respond to missing and you can define method missing and that works. You just have to remember how to write them and then it's like 10 more lines of code. In Rails 5.1, all you need is this. You just have this single method delegate missing two which is exactly what I explained. So if you're going to call a method on order completion and the method does not exist there, then it's going to get called on order. And it's just a single line of code. So I think this is pretty powerful. Okay. Action view. There are actually a few changes in action view and very interesting one. The first one is how do you output an HTML tag with Ruby? In Rails, you actually have two helpers. There is one helper called tag and there is one helper called content tag. If you want to output a tag like br, a breaking line, a way to do it in Rails is tag br nail true. Now that works but you just have to remember the order. Why is it nil there? Why is it true? It is because br doesn't have any content or options so that's why it's nil and also itself closing. But sometimes it's hard to remember and also there is another method, content tag, which you can also use. And you pass div and then the options on the content. In 5.1, this syntax is still available. It's not deprecated but you also have a new syntax where you just call tag dot br or tag dot div. It's basically tag dot and then the HTML tag. And you don't have to remember the order of the argument. And so I think this is really especially important for newcomers when somebody and you come to Rails, they only have to learn one way of creating HTML tags. And I think it's also easier to remember. Now still talking about helpers and views. The next one is I think probably a question that everybody who has ever programmed in Rails has wondered. When you want to create a form, why are there two helpers? Why is there form four and form tag? Sure, they do different things and one accepts a model but it looks so similar that sometimes it's confusing. So what's going to change in 5.1 is that instead of having two helpers to create a form, you have three helpers. There is a new form with. Now the good thing is that this is one to rule them all. So in the long run, the idea is that you're going to switch to form with and then only form with will survive. And for now, nothing has been deprecated. So it's just there. If you create a brand new scaffold app with 5.1, it's going to use form with but for now you can use all of them. So let me just show you how you can upgrade syntax from form four and form tag to form with. If you're using form four, in this case, I'm showing a form to delete a post. You can still do it with form with you have to say actually model post so you have to pass it like that. It just basically syntax difference. If you use form tag, then the first argument is the URL you want to submit to. And with form with you have to specifically say form with URL. Other changes here, for instance, in 5.1, if you create a brand new app form with is going to be remote by default. And also what's pretty interesting is that form with, if you have a block has this F all the time and form tag does not. So with form with you can actually mix the different helpers like submit tag or F dot submit you have the chance to do that. And I think in the end it's going to be less confusing. Okay. I'm think halfway through the list of features. And I think the reason why I made this stock is also really to invite you all to look at the source code and then up for of course upgrade your rates application to 5.1. And also, as my personal way to thank all the people that are mentioned in this slides, the creators of all this for requested contributors. So now let's continue with real ties. The first one is, if you use, if you are in your terminal, you can type rails initializers, and that is going to print out all the initializers of your app. Now the problem is that in 5.0, it's only printing out the method name, and different classes can be using the same method name and you can't really tell. In race 5.1, it's going to output the name of the class and the name of the method. So it's less confusing. And it's more useful, especially if you use race engines, you can just see clearly the order in which they are called. Now let's talk about secrets. Every Rails app has a file config slash secrets.yaml where you can store your secrets, meaning your API keys or any other variable that you want to define once for your environment, your settings, or maybe your email address that you want to use. So there is this secrets.yaml file. And maybe when I'm developing, I want to send all my emails from a specific email address and also when I'm testing, but now when I'm in production. So how do you share one of these variables among different environments? For instance, I want to set my email from to that specific address in development and maybe reuse it in tests. In 5.0, you can already do that. You just have to use this yaml syntax. The ampersand and then remember, like, how, I mean, it's really yaml syntax, but you just have to remember that you have to define the default and then say development, it's using the default. 5.1 is just a little simpler. If you have a section with the name shared, it means that everything that is in that section is going to be available to any environment. So it just makes your code shorter and more readable. This is just one of the changes to the secrets, but there is another one, which is even more important. And that is the addition of encrypted secrets. So as I said before, in this secrets yaml, you can store your secrets, but you probably don't want to store your real production secrets in a plain text file. You don't want to put there your PayPal account information or your API key in production because otherwise everybody who has access just to the source code can be able to access your PayPal and email and everything. So you don't want to put them in plain text right there. As a matter of fact, if you look inside these secrets or yaml, there is a disclaimer and is a comment that says do not keep production secrets in the repository. Instead, read values from the environment. So it is right there. So this is a good advice. But sometimes you need to access your production secrets. You need to install it on a new server or maybe share them with a co-worker. So how do you balance this? How do you balance this? Of having the secrets available, but not in plain text for everybody. This is a new feature of Rails 5.1 and it's encrypted secrets. The way in which it works is that you type Rails secrets set up and this is going to generate two new files. So you can use config secrets yaml.key and config secrets yaml.enc which stands for encrypted. Now the encrypted file is where the secrets are. But if you just try to read this file, you're not going to be able to read them. They're encrypted. In order to open this file, you need to type Rails secrets edit. And this is going to use the key, so the other file, to open it in your editor. Then you can edit, save, and as soon as you close your editor, they're going to be saved encrypted once again. So in short, if you want to read them and edit them, you need both files. But if you just have the encrypted files, then it's okay. You can put that in your repository because people are not going to be able to decrypt them. So the solution is you can put your encrypted files in the repository and you can put it on GitHub and share it. But don't put the key, otherwise this is useless. So keep the key to yourself, share with your coworkers, maybe with a password manager, and then on your server, and then you can have the best of both worlds. You can have encrypted keys. So maybe when you create a new machine, you don't have to manually set 100 environment variables. You just need the key. But then they're encrypted. So if this works for you, it's right there for free in Rails 5.1. If you want to keep on using the other approach of just setting variables in the server, you can still do that. Okay, still talking about Rails.js. Rails.js has seen a lot of great features. jQuery is not a required dependency of Rails anymore, meaning if you don't need it, it's not there. This doesn't mean that we don't like jQuery. I like jQuery. But if it, you know, it's one less library if you don't need it. Let me take a step back. Why was jQuery there in the first place? The main reason was what is called UJS, Unobtrusive JavaScript, and it's for features like this. This is a still arrays scaffold. So you have your list of posts, and for each post you have these links. One of them is destroy. So it's a link to destroy one of your posts. What happens if you click on that link is you're going to see this. You're going to see an alert. This is not the default for links in a browser. Links just work. So it's the JavaScript that it's intercepting your call and showing an alert. And also there is something else here. Normally links cannot do a post or a delete to your server. They just get. So how does this work? It's because there is this UJS that it's looking at the attributes of your link, the data confirm data method, and it's changing things there. So all these came from the jQuery UJS library, which is just JavaScript that has all these features. It looks for these attributes and it changes. There's also data disabled with data remote and so on. Now, if you think about it, you can write the same JavaScript in vanilla JavaScript without jQuery. And that's exactly what happened. A student from the Google Summer of Code of last year for Rails has done this, has rewritten the jQuery UJS library without jQuery. It's now called Rails UJS. It's inside action view. So if you want the exact same features, all you have to do is just require Rails UJS. You don't need to add gems to your gem file. You don't need to require jQuery. It's a smaller footprint and it's exactly the same behavior. Okay, I think I'm going to now get closer to the features you probably have heard of, or maybe that's why you're here in the first place. And I think this is one of them. The original title of this PR was add yarn support in your apps using the dash dash yarn option. I deleted that because since this PR, this has changed. So now it's by default. You don't even need to do dash dash yarn. So whenever you're going to do Rails new with Rails 5.1, you're going to have yarn support. Now let me take a step back. What is yarn? If you are front end developers, you probably have heard of it. It's a package manager for assets or JavaScript libraries. Think of it as bundler and gem file. They are for Ruby gems. Well, if you need to bundle a bunch of JavaScript libraries, yarn is one of the possible solution. And this is really where the Rails team didn't need to reinvent the wheel and create a new one. Yarn has been accepted in the last year as one of the good options. And now it ships with Rails 5.1. So this solves the problem of how can you import a lot of JavaScript libraries in your Rails app? Of course, you could already do that before. You can just copy and paste them in your vendor asset folder. But if it's like one or two, you can manage that. But if you have tens of them, and maybe you need to, if they have dependencies or you need to upgrade them, it becomes complicated. So that's what happens with yarn. Let me show you how you would use yarn with 5.0. And then let me show you what changes in 5.1. In 5.0, you need to install yarn, and then you do yarn init, which sets up the folder. Then you start adding your libraries, for example, bootstrap. These libraries are installed in a folder called node modules. So then you want to ignore this folder, and you have to do that. And also, you have to add this folder to the asset pipeline. And finally, you can just require your libraries. So from 5.0 to 5.1, this happens. There is less setup. There is more convention over configuration. So they're going to be installed in node modules. That folder is already getting ignored. It's already in your pipeline. So it's just very straightforward. And this is leveraging the power of yarn. You can do much more. But this is just really introducing it to the Rails community, and I think it's going to be a great change. Now, you might want to use yarn if you are including, for instance, third-party JavaScript libraries. But what if you are writing JavaScript? What if your app has a lot of JavaScript? Maybe you're using Rails, but then you're writing a single-page app, and you have it all at once. You might start having questions like, in which folder do I put my files? How can I use ES6? How is it going to be pre-compiled? Things like that. So for this, there is another feature in Rails 5.1 that can help you. And that is the fact that you can now leverage Webpacker. So what this means is that there are different ways to structure your JavaScript, let's say, single-page app, and different libraries that you can use. And now with Rails 5.1, you have, once again, a sort of convention over configuration. You have some pretty good defaults. If you do Rails new app dash dash Webpack, a lot of files and folders are going to be created for you. There's going to be an app slash JavaScript folder where you're expected to have your JavaScript in packs. There is a lot of configuration that is written for you in config slash Webpack, and it's separated by environment, development and production. There are some libraries that are there already for you that you're probably going to need, like Webpacker, and Webpacker, and Webpacker, and Webpacker to use Webpacker, Webpacker is available, or, you know, Coffee, SAS files are already ignored, and then there are some bin files, Webpack, WebServer, Webpack, Watcher, and Webpacker. So all this is there for you. In the past if you had to use Webpack with Rails, you had to install it and then decide that I had to do some configuration and stuff, Locally, you can type Webpack Dev Server, which is one of those new commands that come with it. And this is going to watch your folder, your app JavaScript. And as you type, even if it's your six, it's going to watch that folder and then make it available for you so you can develop and have those JavaScript available in your app. The way in which you include those in your app is with this new helper JavaScript pack tag, where you specify which pack you want to load. And if you also have style sheets, you have style sheet pack tag. And there are many, many other features. For instance, you can interpolate Ruby. You can use, you know, a Routes helper. So you just do application.js.erb. There is really a lot that I cannot cover, but all of this is powered by a new jam called Webpacker. And it's open source. It's available on GitHub, Rails slash Webpacker. So feel free to go there and look at what's happening there. Also, this, for instance, works right away if you want to deploy on Heroku or the precompilation. And the last thing I want to mention is that when you do Rails new dash dash Webpack, you can specify as an option, React, View or Angular, which is going to install and configure more libraries for you. So if you need to use TypeScript or JSX, it's all there for you. Okay, I'm going to talk about Action Pack last. If you go and download my slides, I have more slides about Action Mailer and ActiveJob that I'm not going to be able to touch here. But let me just talk about Action Pack. The first feature is actually a mix between Action Pack and Railties, Cappy Bar Integration with Rails, also known as System Test. If you were in this room yesterday, you saw an amazing talk by Eileen Ishitel, who created this PR, and she spent 40 minutes on this feature. I'm just going to try to summarize in two minutes, but you should probably go and re-watch her talk on YouTube. So in summary, System Test, I'm still making an example with Skaffold. If you have a Skaffold, an example of System Test is when I go to the page slash post, I actually want to ensure that in the browser, in the header H1, the text says exactly post. Like I want to test exactly the final result in the browser, not just a unit test. So how do you write this sort of test? In Rails 5.0, you have to make a decision which library I'm going to use, which version, how to install it. As an example, you can decide that to your Gemfire, you're going to add Cappy Bar and Selenium WebDriver. Then before you run your test, you have to require those libraries. Then you have to write a lot of configuration. This is just a very small example. Like you're going to say that Cappy Bar is going to be driven by Selenium. You're going to use Chrome. You might specify a resolution. And then after you do all of these, you can write the test. Now, the test itself is not super complicated. It has basically two lines. You visit slash post, and then you assert that inside the H1, the text is what you expect. So it's really about making everything else go away and focus right in the test. So in Rails 5.1, forget about the setup. All you have to do is write your test. Your test is going to inherit from a class called application system test case, which is going to set up all that for you. You can also use route helpers like post underscore URL. And then you're going to write your system test with Rails test system. So much more convenient. And also it has great new features like screenshots that are taken if your test fail, clean the database. And one more thing is that the old type of functional controller test are not going to be generated anymore when you have a new 5.1 app. You're going to see this type of test. The other ones are still going to be running for backward compatibility. And I'm going to talk about the last feature in Action Pack, which is, I guess, my favorite one. And this is one example of a PR that it's a single PR, but it's like five features in a single PR. And in short, it's adding two new methods that you can use in your config routes. But these methods are very powerful. They're called direct and resolve. And I'm just going to go through two examples that show what they do. But once again, go and check the code because they can do much more. The first one, still a scaffold. This is a post page. And then imagine that below the post, you have comments. So each comment does not live on its own page, like slash comments slash one, it lives inside the post page. Now, imagine that you want to link to one of these comments. How do you write that code? It's not that it's hard to write the code in 5.0, for instance, you can say, link to comment number two, post path, because the page is the post page. So you do post path and then you say anchor content two, because you're basically linking to the post page at a specific place in that. But I believe that all this logic should belong to the routes, not to the view. When you do a link, you just want to say I'm linking to some embedded content. And then the routes are, you know, it's the responsibility of the routes to route. So to say, oh, it's a link to a comment, but the comment is actually, you know, inside the post at a certain anchor. So this new direct method, let's you do that. Let's you define once in your routes this style of routes. And then your views can just be used with link to super simple. So it's very powerful, especially this might sound like a kind of simple example, but you have if you have more polymorphic resources, this can help a lot. The other new method solves several problems. And one of these problems is if you have a form that's that post to a singular resource. For instance, if you have a form that lets user update their profile or create a profile, a user has one profile, not many. So you might want to do a form that submits to slash profile singular. Now, if you try to do this just by doing form for at profile in Rails until five point zero, you would see an error. It's saying undefined method profiles path plural because by default, all the routes are plural, even though you say resource singular in your routes file. There is a work around for this, but this has actually been an issue in the GitHub in the rails GitHub since 2011. People have been asking why is it like this? Can we just make it, you know, work just work. So in five point zero, the work around was when you do form for at profile, you have to specify the URL. You're saying, yes, it's a form to a singular profile, but I have to explicitly say this is my URL. And if you have a form to update, you have to do it. If you have a form to destroy, you have to do it. You have to do multiple times. In five point one, you can add this resolve profile, which is the name of the class as a string and then profile. You just do that once. And then it's that one is basically saying the routes for a single profile. It's basically just going to work. And you do that once and you do that in your routes file, which is probably where you should do it. And we that I have one minute left. So I'm just going to leave it here, but feel free to go and look at more features there. And also feel free to go and look at the changelog files inside the libraries. And then once five point one ships, there's also going to be a guide to upgrade your apps from five point zero to five point one. And I just want to thank all the people who have contributed to Rails and all the people here who are going to maybe start contributing to Rails. And that's what I have. Thank you very much.
 Music  My name is Fabio and today I'm going to talk to you about Rails 5.1, which is the latest release of the framework that we all love and enjoy.  And the slides are available online and you might want to go there simply because there are links to the pull request that I'm going to talk about.  So I only have 40 minutes. I can't go into details, but I invite you to go there and see at the commits at the discussion and hopefully get involved you with open source.  To give you a little bit of context, 5.1 is going to be released any minute now, any day now.  But just to give you an idea, when 5.0 was released, that was the result of 18 months of work and about 10,000 commits, about 1,000 committers.  So with 5.1, you can think of it as kind of half of it, nine months of work, about 4,000 commits.  I did this just with the git command and if you actually go and look at the git diff, you're going to see a lot of lines that have changed in the code base.  And one of the reasons is that the Rails team is now using Rubikop for styling.  So you're going to see many things like spaces, single quotes, double quotes, but that is not really going to affect you as users of Rails.  So that is what I'm going to talk about today.  If you use Rails, how is this new version going to affect you?  And so what I'm going to talk about is breaking changes, then active record, active support, action view, real ties, and action pack.  And so the last disclaimer before starting is that I have cats in this talk, so I'm going to start with the first one.  Okay, breaking changes.  Okay, breaking changes.  Really, I have upgraded my apps to 5.1 and I haven't really encountered many that have affected me. I found some in the code that I'm going to talk about, but they are not that big.  I'm going to start with the first one, which is the engine that reads your ERB files under the hood has changed from a Ruby to a Ruby.  And the difference is not just an S at the end, it's also that a Ruby was now really being maintained since 2011, and a Ruby has a simpler internals and a smaller memory footprint.  Now, if all you're doing in your app is just having ERB files, this is not going to affect you at all because the result is the same.  This is only going to affect you if you actually are explicitly calling a Ruby in your code. For instance, if you have a jam, like Hamel or something that touches action view, then you might want to look at this.  Otherwise, it just a benefit for you. It's going to be faster.  The next one is when you set or skip callbacks, you can add conditions. You can say set if, skip if.  And these conditions, you can pass them as strings.  And let me show you what it means.  I tried to write an example here if you have a post in your database, and then before you save this post, if it doesn't have the title, so unless the title is present, you want to set no title, that unless you could pass a string in 5.0.  Same with if.  Now, if this feels weird, it did feel weird to me. It's because there are alternatives to do this. So in 5.1, you're not going to be able to use a string anymore.  But you can still, like, use a proc. You can still use a symbol. So if you're using strings for those conditions, then you might want to change to this new syntax.  Still talking about breaking changes. This affects your config routes.  When you set your routes, you're also going to use strings. You're going to say get dashboard index to home, things like that.  So in this string, there are actually a couple of special symbols that you can use in your routes. You can do get and then this column controller was less colon action was less colon ID.  So this kind of syntax was valid until race five. And these are wild cards. So if you have that in your routes, you're basically saying match any controller with any action or any ID.  This is really powerful, but also it was the cause of a couple of security issues that have already been fixed in previous version of rails.  So this decision was made so that going forward, this syntax would not be acceptable anymore. Instead, if you have many controllers or actions, you might want to whitelist them explicitly, which I also think makes for better and cleaner code.  That's that's what I have so far for breaking changes. I'm not claiming these are all of them and I invite you to go and look at the changelog of the libraries. But I think it just gives you an idea about the fact that it's probably not going to be hard for you to upgrade to race 5.1.  And so now we can start looking at the feature what has been added or improved and what can benefit your everyday work.  Let's start with active record.  Primary keys in your database, they used to be integers and now they can be big in or big serial if you impose grass. So you basically have 64 bit. So if you have, if you need to reference many records in database now, this is the default.  You just have big in as your primary keys. This can be useful.  And still talking about databases. This is only for my SQL or equivalent Maria DB.  There is no support for virtual columns.  I also, I'm going to show an example for this.  Let's say you have a user stable every user has a name.  Now every user, you can also say has an upper name which is just the uppercase version of the name.  My SQL lets you do that with this upper name in SQL.  So basically SQL has this virtual column, which is not like duplicate to just calculating the uppercase version.  And now you can reference this column in your migration by writing playing Ruby, you just do to the virtual upper name.  And it has even more features. Let's say you have another virtual column, which is name length, which is the number of characters of the name.  You can tell my SQL to store this column and also to index by this column.  So if you want to display your users sorted by the number of characters, you know, my SQL can do all of this.  And this is all the code you need.  And what is good about this is that you don't have to write your structure dot SQL, you can just write Ruby, which I guess we all prefer.  Still talking about database.  If you have to deal with many, many records like thousands of records.  Active record provides methods to do this like find each or in batches.  So if you wanted to iterate 5000 posts, you want to do maybe find each.  And this works.  There was just one gotcha that in 5.0.  If you wanted to use the limit method, it wasn't really working.  If you had to write post limit 500.pn each, you would actually get a warning saying scoped order and limit are ignored.  And so the query would just fetch 1000 because that's the default in 5.1.  The limit method is now supported.  So that's good.  Okay.  I think I'm going a little fast on this initial new features.  It's because maybe you've not heard about them. And hopefully I'm getting you curious about going to see everything that has changed.  So bear with me and we're going to get to the end where you're probably going to see the features that have made the news or that other presenters are talking about here.  But let's continue with active support.  There is no support for Unicode nine.  And here's an example of what this entails.  Well, the value of the constant Unicode version is now nine and not eight.  And as an example, let's say you have a string and this string has just a single emoji.  This emoji is called a family with two mothers, one daughter and one son.  This is one character. It's one emoji.  But in 5.0, if you had asked for the length of this string, you would have gotten four.  If you had asked to reverse this string, the family would have been split into four characters, which is probably not what you wanted.  And so now in 5.1, there is full support for Unicode nine and families are not going to be separated anymore.  Active support duration has two methods called since and until.  And now they have aliases after and before.  So it's easy to understand with an example.  If in your code, you're writing two weeks since Christmas Day.  Now you can say two weeks after Christmas Day.  It's the same thing, but it might sound more natural and English.  Five days until Christmas Day, you now have the option to say five days before Christmas Day, maybe in your test.  This is something that you like better.  Now you have the option.  Let's get to one of the bigger request.  There's a new method in module called delegate miss into.  I think this is going to be very powerful for people who use the delegator pattern.  So if you have a class with a bunch of methods, and then you have another class that wraps the first one, basically it's calling all the methods of the first one except couple.  And this can help you.  Let me show you how.  I made another example here.  Imagine have an order active record in order in your database so users can create orders, save order, destroy order.  So that's just an active record base.  And then you have another class called order completion that is delegating all the methods to the order.  So it's doing everything that the order does except for create when an order completion is created.  It's also sending a notification.  This is a pattern that you can do in Rails and a way to do this it's using the delegate method which already existed.  The problem with the delegate method is that you have to list all the methods that you want to delegate.  So it might not be your first choice.  Another way to do this is to use Ruby's metaprogramming methods.  You can find respond to missing and you can define method missing and that works.  You just have to remember how to write them and then it's like 10 more lines of code.  In Rails 5.1, all you need is this.  You just have this single method delegate missing two which is exactly what I explained.  So if you're going to call a method on order completion and the method does not exist there, then it's going to get called on order.  And it's just a single line of code.  So I think this is pretty powerful.  Okay.  Action view.  There are actually a few changes in action view and very interesting one.  The first one is how do you output an HTML tag with Ruby?  In Rails, you actually have two helpers.  There is one helper called tag and there is one helper called content tag.  If you want to output a tag like br, a breaking line, a way to do it in Rails is tag br nail true.  Now that works but you just have to remember the order.  Why is it nil there?  Why is it true?  It is because br doesn't have any content or options so that's why it's nil and also itself closing.  But sometimes it's hard to remember and also there is another method, content tag, which you can also use.  And you pass div and then the options on the content.  In 5.1, this syntax is still available.  It's not deprecated but you also have a new syntax where you just call tag dot br or tag dot div.  It's basically tag dot and then the HTML tag.  And you don't have to remember the order of the argument.  And so I think this is really especially important for newcomers when somebody and you come to Rails,  they only have to learn one way of creating HTML tags.  And I think it's also easier to remember.  Now still talking about helpers and views.  The next one is I think probably a question that everybody who has ever programmed in Rails has wondered.  When you want to create a form, why are there two helpers?  Why is there form four and form tag?  Sure, they do different things and one accepts a model but it looks so similar that sometimes it's confusing.  So what's going to change in 5.1 is that instead of having two helpers to create a form, you have three helpers.  There is a new form with.  Now the good thing is that this is one to rule them all.  So in the long run, the idea is that you're going to switch to form with and then only form with will survive.  And for now, nothing has been deprecated.  So it's just there.  If you create a brand new scaffold app with 5.1, it's going to use form with but for now you can use all of them.  So let me just show you how you can upgrade syntax from form four and form tag to form with.  If you're using form four, in this case, I'm showing a form to delete a post.  You can still do it with form with you have to say actually model post so you have to pass it like that.  It just basically syntax difference.  If you use form tag, then the first argument is the URL you want to submit to.  And with form with you have to specifically say form with URL.  Other changes here, for instance, in 5.1, if you create a brand new app form with is going to be remote by default.  And also what's pretty interesting is that form with, if you have a block has this F all the time and form tag does not.  So with form with you can actually mix the different helpers like submit tag or F dot submit you have the chance to do that.  And I think in the end it's going to be less confusing.  Okay.  I'm think halfway through the list of features.  And I think the reason why I made this stock is also really to invite you all to look at the source code and then up for of course upgrade your rates application to 5.1.  And also, as my personal way to thank all the people that are mentioned in this slides, the creators of all this for requested contributors.  So now let's continue with real ties.  The first one is, if you use, if you are in your terminal, you can type rails initializers, and that is going to print out all the initializers of your app.  Now the problem is that in 5.0, it's only printing out the method name, and different classes can be using the same method name and you can't really tell.  In race 5.1, it's going to output the name of the class and the name of the method. So it's less confusing. And it's more useful, especially if you use race engines, you can just see clearly the order in which they are called.  Now let's talk about secrets. Every Rails app has a file config slash secrets.yaml where you can store your secrets, meaning your API keys or any other variable that you want to define once for your environment, your settings, or maybe your email address that you want to use.  So there is this secrets.yaml file. And maybe when I'm developing, I want to send all my emails from a specific email address and also when I'm testing, but now when I'm in production.  So how do you share one of these variables among different environments? For instance, I want to set my email from to that specific address in development and maybe reuse it in tests.  In 5.0, you can already do that. You just have to use this yaml syntax. The ampersand and then remember, like, how, I mean, it's really yaml syntax, but you just have to remember that you have to define the default and then say development, it's using the default.  5.1 is just a little simpler. If you have a section with the name shared, it means that everything that is in that section is going to be available to any environment. So it just makes your code shorter and more readable.  This is just one of the changes to the secrets, but there is another one, which is even more important. And that is the addition of encrypted secrets.  So as I said before, in this secrets yaml, you can store your secrets, but you probably don't want to store your real production secrets in a plain text file. You don't want to put there your PayPal account information or your API key in production because otherwise everybody who has access just to the source code can be able to access your  PayPal and email and everything. So you don't want to put them in plain text right there.  As a matter of fact, if you look inside these secrets or yaml, there is a disclaimer and is a comment that says do not keep production secrets in the repository. Instead, read values from the environment. So it is right there.  So this is a good advice. But sometimes you need to access your production secrets. You need to install it on a new server or maybe share them with a co-worker. So how do you balance this?  How do you balance this? Of having the secrets available, but not in plain text for everybody. This is a new feature of Rails 5.1 and it's encrypted secrets. The way in which it works is that you type Rails secrets set up and this is going to generate two new files.  So you can use config secrets yaml.key and config secrets yaml.enc which stands for encrypted. Now the encrypted file is where the secrets are. But if you just try to read this file, you're not going to be able to read them. They're encrypted.  In order to open this file, you need to type Rails secrets edit. And this is going to use the key, so the other file, to open it in your editor. Then you can edit, save, and as soon as you close your editor, they're going to be saved encrypted once again.  So in short, if you want to read them and edit them, you need both files. But if you just have the encrypted files, then it's okay. You can put that in your repository because people are not going to be able to decrypt them.  So the solution is you can put your encrypted files in the repository and you can put it on GitHub and share it. But don't put the key, otherwise this is useless. So keep the key to yourself, share with your coworkers, maybe with a password manager, and then on your server, and then you can have the best of both worlds.  You can have encrypted keys. So maybe when you create a new machine, you don't have to manually set 100 environment variables. You just need the key. But then they're encrypted. So if this works for you, it's right there for free in Rails 5.1.  If you want to keep on using the other approach of just setting variables in the server, you can still do that.  Okay, still talking about Rails.js. Rails.js has seen a lot of great features.  jQuery is not a required dependency of Rails anymore, meaning if you don't need it, it's not there.  This doesn't mean that we don't like jQuery. I like jQuery. But if it, you know, it's one less library if you don't need it.  Let me take a step back. Why was jQuery there in the first place? The main reason was what is called UJS, Unobtrusive JavaScript, and it's for features like this.  This is a still arrays scaffold. So you have your list of posts, and for each post you have these links. One of them is destroy. So it's a link to destroy one of your posts.  What happens if you click on that link is you're going to see this. You're going to see an alert. This is not the default for links in a browser.  Links just work. So it's the JavaScript that it's intercepting your call and showing an alert. And also there is something else here.  Normally links cannot do a post or a delete to your server. They just get. So how does this work?  It's because there is this UJS that it's looking at the attributes of your link, the data confirm data method, and it's changing things there.  So all these came from the jQuery UJS library, which is just JavaScript that has all these features. It looks for these attributes and it changes.  There's also data disabled with data remote and so on.  Now, if you think about it, you can write the same JavaScript in vanilla JavaScript without jQuery.  And that's exactly what happened. A student from the Google Summer of Code of last year for Rails has done this, has rewritten the jQuery UJS library without jQuery.  It's now called Rails UJS. It's inside action view. So if you want the exact same features, all you have to do is just require Rails UJS.  You don't need to add gems to your gem file. You don't need to require jQuery. It's a smaller footprint and it's exactly the same behavior.  Okay, I think I'm going to now get closer to the features you probably have heard of, or maybe that's why you're here in the first place.  And I think this is one of them. The original title of this PR was add yarn support in your apps using the dash dash yarn option.  I deleted that because since this PR, this has changed. So now it's by default. You don't even need to do dash dash yarn.  So whenever you're going to do Rails new with Rails 5.1, you're going to have yarn support.  Now let me take a step back. What is yarn? If you are front end developers, you probably have heard of it.  It's a package manager for assets or JavaScript libraries. Think of it as bundler and gem file. They are for Ruby gems.  Well, if you need to bundle a bunch of JavaScript libraries, yarn is one of the possible solution.  And this is really where the Rails team didn't need to reinvent the wheel and create a new one. Yarn has been accepted in the last year as one of the good options.  And now it ships with Rails 5.1. So this solves the problem of how can you import a lot of JavaScript libraries in your Rails app?  Of course, you could already do that before. You can just copy and paste them in your vendor asset folder. But if it's like one or two, you can manage that.  But if you have tens of them, and maybe you need to, if they have dependencies or you need to upgrade them, it becomes complicated.  So that's what happens with yarn. Let me show you how you would use yarn with 5.0. And then let me show you what changes in 5.1.  In 5.0, you need to install yarn, and then you do yarn init, which sets up the folder. Then you start adding your libraries, for example, bootstrap.  These libraries are installed in a folder called node modules. So then you want to ignore this folder, and you have to do that.  And also, you have to add this folder to the asset pipeline. And finally, you can just require your libraries.  So from 5.0 to 5.1, this happens. There is less setup. There is more convention over configuration.  So they're going to be installed in node modules. That folder is already getting ignored. It's already in your pipeline.  So it's just very straightforward. And this is leveraging the power of yarn. You can do much more.  But this is just really introducing it to the Rails community, and I think it's going to be a great change.  Now, you might want to use yarn if you are including, for instance, third-party JavaScript libraries.  But what if you are writing JavaScript? What if your app has a lot of JavaScript?  Maybe you're using Rails, but then you're writing a single-page app, and you have it all at once.  You might start having questions like, in which folder do I put my files? How can I use ES6?  How is it going to be pre-compiled? Things like that.  So for this, there is another feature in Rails 5.1 that can help you.  And that is the fact that you can now leverage Webpacker.  So what this means is that there are different ways to structure your JavaScript, let's say, single-page app,  and different libraries that you can use. And now with Rails 5.1, you have, once again, a sort of convention over configuration.  You have some pretty good defaults.  If you do Rails new app dash dash Webpack, a lot of files and folders are going to be created for you.  There's going to be an app slash JavaScript folder where you're expected to have your JavaScript in packs.  There is a lot of configuration that is written for you in config slash Webpack, and it's separated by environment,  development and production. There are some libraries that are there already for you that you're probably going to need,  like Webpacker, and Webpacker, and Webpacker, and Webpacker to use Webpacker, Webpacker is available,  or, you know, Coffee, SAS files are already ignored, and then there are some bin files, Webpack, WebServer, Webpack,  Watcher, and Webpacker.  So all this is there for you.  In the past if you had to use Webpack with Rails, you had to install it and then decide that I had to do some configuration and stuff,  Locally, you can type Webpack Dev Server, which is one of those new commands that come with it.  And this is going to watch your folder, your app JavaScript.  And as you type, even if it's your six, it's going to watch that folder and then make it available for you so you can develop and have those JavaScript available in your app.  The way in which you include those in your app is with this new helper JavaScript pack tag, where you specify which pack you want to load.  And if you also have style sheets, you have style sheet pack tag.  And there are many, many other features. For instance, you can interpolate Ruby. You can use, you know, a Routes helper.  So you just do application.js.erb. There is really a lot that I cannot cover, but all of this is powered by a new jam called Webpacker.  And it's open source. It's available on GitHub, Rails slash Webpacker.  So feel free to go there and look at what's happening there.  Also, this, for instance, works right away if you want to deploy on Heroku or the precompilation.  And the last thing I want to mention is that when you do Rails new dash dash Webpack, you can specify as an option, React, View or Angular,  which is going to install and configure more libraries for you. So if you need to use TypeScript or JSX, it's all there for you.  Okay, I'm going to talk about Action Pack last. If you go and download my slides, I have more slides about Action Mailer and ActiveJob that I'm not going to be able to touch here.  But let me just talk about Action Pack.  The first feature is actually a mix between Action Pack and Railties, Cappy Bar Integration with Rails, also known as System Test.  If you were in this room yesterday, you saw an amazing talk by Eileen Ishitel, who created this PR, and she spent 40 minutes on this feature.  I'm just going to try to summarize in two minutes, but you should probably go and re-watch her talk on YouTube.  So in summary, System Test, I'm still making an example with Skaffold. If you have a Skaffold, an example of System Test is when I go to the page slash post,  I actually want to ensure that in the browser, in the header H1, the text says exactly post. Like I want to test exactly the final result in the browser, not just a unit test.  So how do you write this sort of test?  In Rails 5.0, you have to make a decision which library I'm going to use, which version, how to install it.  As an example, you can decide that to your Gemfire, you're going to add Cappy Bar and Selenium WebDriver.  Then before you run your test, you have to require those libraries.  Then you have to write a lot of configuration. This is just a very small example. Like you're going to say that Cappy Bar is going to be driven by Selenium.  You're going to use Chrome. You might specify a resolution.  And then after you do all of these, you can write the test.  Now, the test itself is not super complicated. It has basically two lines.  You visit slash post, and then you assert that inside the H1, the text is what you expect.  So it's really about making everything else go away and focus right in the test.  So in Rails 5.1, forget about the setup. All you have to do is write your test.  Your test is going to inherit from a class called application system test case, which is going to set up all that for you.  You can also use route helpers like post underscore URL.  And then you're going to write your system test with Rails test system.  So much more convenient. And also it has great new features like screenshots that are taken if your test fail, clean the database.  And one more thing is that the old type of functional controller test are not going to be generated anymore when you have a new 5.1 app.  You're going to see this type of test. The other ones are still going to be running for backward compatibility.  And I'm going to talk about the last feature in Action Pack, which is, I guess, my favorite one.  And this is one example of a PR that it's a single PR, but it's like five features in a single PR.  And in short, it's adding two new methods that you can use in your config routes.  But these methods are very powerful. They're called direct and resolve.  And I'm just going to go through two examples that show what they do.  But once again, go and check the code because they can do much more.  The first one, still a scaffold. This is a post page.  And then imagine that below the post, you have comments.  So each comment does not live on its own page, like slash comments slash one, it lives inside the post page.  Now, imagine that you want to link to one of these comments.  How do you write that code?  It's not that it's hard to write the code in 5.0, for instance, you can say, link to comment number two, post path,  because the page is the post page.  So you do post path and then you say anchor content two, because you're basically linking to the post page at a specific place in that.  But I believe that all this logic should belong to the routes, not to the view.  When you do a link, you just want to say I'm linking to some embedded content.  And then the routes are, you know, it's the responsibility of the routes to route.  So to say, oh, it's a link to a comment, but the comment is actually, you know, inside the post at a certain anchor.  So this new direct method, let's you do that.  Let's you define once in your routes this style of routes.  And then your views can just be used with link to super simple.  So it's very powerful, especially this might sound like a kind of simple example, but you have if you have more polymorphic resources, this can help a lot.  The other new method solves several problems.  And one of these problems is if you have a form that's that post to a singular resource.  For instance, if you have a form that lets user update their profile or create a profile, a user has one profile, not many.  So you might want to do a form that submits to slash profile singular.  Now, if you try to do this just by doing form for at profile in Rails until five point zero, you would see an error.  It's saying undefined method profiles path plural because by default, all the routes are plural, even though you say resource singular in your routes file.  There is a work around for this, but this has actually been an issue in the GitHub in the rails GitHub since 2011.  People have been asking why is it like this? Can we just make it, you know, work just work.  So in five point zero, the work around was when you do form for at profile, you have to specify the URL.  You're saying, yes, it's a form to a singular profile, but I have to explicitly say this is my URL.  And if you have a form to update, you have to do it. If you have a form to destroy, you have to do it.  You have to do multiple times. In five point one, you can add this resolve profile, which is the name of the class as a string and then profile.  You just do that once. And then it's that one is basically saying the routes for a single profile.  It's basically just going to work. And you do that once and you do that in your routes file, which is probably where you should do it.  And we that I have one minute left. So I'm just going to leave it here, but feel free to go and look at more features there.  And also feel free to go and look at the changelog files inside the libraries.  And then once five point one ships, there's also going to be a guide to upgrade your apps from five point zero to five point one.  And I just want to thank all the people who have contributed to Rails and all the people here who are going to maybe start contributing to Rails.  And that's what I have. Thank you very much.
Rails_5_1_0_311.png Rails_5_1_312_3263.png Rails_5_1_3264_3719.png Rails_5_1_3720_3827.png Rails_5_1_3828_5483.png Rails_5_1_5484_8171.png Rails_5_1_8172_8279.png Rails_5_1_8280_8363.png Rails_5_1_8364_8459.png Rails_5_1_8460_8507.png Rails_5_1_8508_8555.png Rails_5_1_8556_8675.png Rails_5_1_8676_8723.png Rails_5_1_8724_8807.png Rails_5_1_8808_8915.png Rails_5_1_8916_9599.png Rails_5_1_9600_12335.png Rails_5_1_12336_12983.png Rails_5_1_12984_13031.png Rails_5_1_13032_13151.png Rails_5_1_13152_13211.png Rails_5_1_13212_13259.png Rails_5_1_13260_13319.png Rails_5_1_13320_13367.png Rails_5_1_13368_13427.png Rails_5_1_13428_13475.png Rails_5_1_13476_13535.png Rails_5_1_13536_13583.png Rails_5_1_13584_13691.png Rails_5_1_13692_13751.png Rails_5_1_13752_13811.png Rails_5_1_13812_16067.png Rails_5_1_16068_19031.png Rails_5_1_19032_19271.png Rails_5_1_19272_25043.png Rails_5_1_25044_25127.png Rails_5_1_25128_25223.png Rails_5_1_25224_25271.png Rails_5_1_25272_25319.png Rails_5_1_25320_25427.png Rails_5_1_25428_25487.png Rails_5_1_25488_25571.png Rails_5_1_25572_25691.png Rails_5_1_25692_25739.png Rails_5_1_25740_25883.png Rails_5_1_25884_25967.png Rails_5_1_25968_28187.png Rails_5_1_28188_34235.png Rails_5_1_34236_36923.png Rails_5_1_36924_47243.png Rails_5_1_47244_47735.png Rails_5_1_47736_49403.png Rails_5_1_49404_50027.png Rails_5_1_50028_53543.png Rails_5_1_53544_59087.png Rails_5_1_59088_59219.png Rails_5_1_59220_59258.png
Music My name is Fabio and today I'm going to talk to you about Rails 5.1, which is the latest release of the framework that we all love and enjoy. And the slides are available online and you might want to go there simply because there are links to the pull request that I'm going to talk about. So I only have 40 minutes. I can't go into details, but I invite you to go there and see at the commits at the discussion and hopefully get involved you with open source. To give you a little bit of context, 5.1 is going to be released any minute now, any day now. But just to give you an idea, when 5.0 was released, that was the result of 18 months of work and about 10,000 commits, about 1,000 committers. So with 5.1, you can think of it as kind of half of it, nine months of work, about 4,000 commits. I did this just with the git command and if you actually go and look at the git diff, you're going to see a lot of lines that have changed in the code base. And one of the reasons is that the Rails team is now using Rubikop for styling. So you're going to see many things like spaces, single quotes, double quotes, but that is not really going to affect you as users of Rails. So that is what I'm going to talk about today. If you use Rails, how is this new version going to affect you? And so what I'm going to talk about is breaking changes, then active record, active support, action view, real ties, and action pack. And so the last disclaimer before starting is that I have cats in this talk, so I'm going to start with the first one. Okay, breaking changes. Okay, breaking changes. Really, I have upgraded my apps to 5.1 and I haven't really encountered many that have affected me. I found some in the code that I'm going to talk about, but they are not that big. I'm going to start with the first one, which is the engine that reads your ERB files under the hood has changed from a Ruby to a Ruby. And the difference is not just an S at the end, it's also that a Ruby was now really being maintained since 2011, and a Ruby has a simpler internals and a smaller memory footprint. Now, if all you're doing in your app is just having ERB files, this is not going to affect you at all because the result is the same. This is only going to affect you if you actually are explicitly calling a Ruby in your code. For instance, if you have a jam, like Hamel or something that touches action view, then you might want to look at this. Otherwise, it just a benefit for you. It's going to be faster. The next one is when you set or skip callbacks, you can add conditions. You can say set if, skip if. And these conditions, you can pass them as strings. And let me show you what it means. I tried to write an example here if you have a post in your database, and then before you save this post, if it doesn't have the title, so unless the title is present, you want to set no title, that unless you could pass a string in 5.0. Same with if. Now, if this feels weird, it did feel weird to me. It's because there are alternatives to do this. So in 5.1, you're not going to be able to use a string anymore. But you can still, like, use a proc. You can still use a symbol. So if you're using strings for those conditions, then you might want to change to this new syntax. Still talking about breaking changes. This affects your config routes. When you set your routes, you're also going to use strings. You're going to say get dashboard index to home, things like that. So in this string, there are actually a couple of special symbols that you can use in your routes. You can do get and then this column controller was less colon action was less colon ID. So this kind of syntax was valid until race five. And these are wild cards. So if you have that in your routes, you're basically saying match any controller with any action or any ID. This is really powerful, but also it was the cause of a couple of security issues that have already been fixed in previous version of rails. So this decision was made so that going forward, this syntax would not be acceptable anymore. Instead, if you have many controllers or actions, you might want to whitelist them explicitly, which I also think makes for better and cleaner code. That's that's what I have so far for breaking changes. I'm not claiming these are all of them and I invite you to go and look at the changelog of the libraries. But I think it just gives you an idea about the fact that it's probably not going to be hard for you to upgrade to race 5.1. And so now we can start looking at the feature what has been added or improved and what can benefit your everyday work. Let's start with active record. Primary keys in your database, they used to be integers and now they can be big in or big serial if you impose grass. So you basically have 64 bit. So if you have, if you need to reference many records in database now, this is the default. You just have big in as your primary keys. This can be useful. And still talking about databases. This is only for my SQL or equivalent Maria DB. There is no support for virtual columns. I also, I'm going to show an example for this. Let's say you have a user stable every user has a name. Now every user, you can also say has an upper name which is just the uppercase version of the name. My SQL lets you do that with this upper name in SQL. So basically SQL has this virtual column, which is not like duplicate to just calculating the uppercase version. And now you can reference this column in your migration by writing playing Ruby, you just do to the virtual upper name. And it has even more features. Let's say you have another virtual column, which is name length, which is the number of characters of the name. You can tell my SQL to store this column and also to index by this column. So if you want to display your users sorted by the number of characters, you know, my SQL can do all of this. And this is all the code you need. And what is good about this is that you don't have to write your structure dot SQL, you can just write Ruby, which I guess we all prefer. Still talking about database. If you have to deal with many, many records like thousands of records. Active record provides methods to do this like find each or in batches. So if you wanted to iterate 5000 posts, you want to do maybe find each. And this works. There was just one gotcha that in 5.0. If you wanted to use the limit method, it wasn't really working. If you had to write post limit 500.pn each, you would actually get a warning saying scoped order and limit are ignored. And so the query would just fetch 1000 because that's the default in 5.1. The limit method is now supported. So that's good. Okay. I think I'm going a little fast on this initial new features. It's because maybe you've not heard about them. And hopefully I'm getting you curious about going to see everything that has changed. So bear with me and we're going to get to the end where you're probably going to see the features that have made the news or that other presenters are talking about here. But let's continue with active support. There is no support for Unicode nine. And here's an example of what this entails. Well, the value of the constant Unicode version is now nine and not eight. And as an example, let's say you have a string and this string has just a single emoji. This emoji is called a family with two mothers, one daughter and one son. This is one character. It's one emoji. But in 5.0, if you had asked for the length of this string, you would have gotten four. If you had asked to reverse this string, the family would have been split into four characters, which is probably not what you wanted. And so now in 5.1, there is full support for Unicode nine and families are not going to be separated anymore. Active support duration has two methods called since and until. And now they have aliases after and before. So it's easy to understand with an example. If in your code, you're writing two weeks since Christmas Day. Now you can say two weeks after Christmas Day. It's the same thing, but it might sound more natural and English. Five days until Christmas Day, you now have the option to say five days before Christmas Day, maybe in your test. This is something that you like better. Now you have the option. Let's get to one of the bigger request. There's a new method in module called delegate miss into. I think this is going to be very powerful for people who use the delegator pattern. So if you have a class with a bunch of methods, and then you have another class that wraps the first one, basically it's calling all the methods of the first one except couple. And this can help you. Let me show you how. I made another example here. Imagine have an order active record in order in your database so users can create orders, save order, destroy order. So that's just an active record base. And then you have another class called order completion that is delegating all the methods to the order. So it's doing everything that the order does except for create when an order completion is created. It's also sending a notification. This is a pattern that you can do in Rails and a way to do this it's using the delegate method which already existed. The problem with the delegate method is that you have to list all the methods that you want to delegate. So it might not be your first choice. Another way to do this is to use Ruby's metaprogramming methods. You can find respond to missing and you can define method missing and that works. You just have to remember how to write them and then it's like 10 more lines of code. In Rails 5.1, all you need is this. You just have this single method delegate missing two which is exactly what I explained. So if you're going to call a method on order completion and the method does not exist there, then it's going to get called on order. And it's just a single line of code. So I think this is pretty powerful. Okay. Action view. There are actually a few changes in action view and very interesting one. The first one is how do you output an HTML tag with Ruby? In Rails, you actually have two helpers. There is one helper called tag and there is one helper called content tag. If you want to output a tag like br, a breaking line, a way to do it in Rails is tag br nail true. Now that works but you just have to remember the order. Why is it nil there? Why is it true? It is because br doesn't have any content or options so that's why it's nil and also itself closing. But sometimes it's hard to remember and also there is another method, content tag, which you can also use. And you pass div and then the options on the content. In 5.1, this syntax is still available. It's not deprecated but you also have a new syntax where you just call tag dot br or tag dot div. It's basically tag dot and then the HTML tag. And you don't have to remember the order of the argument. And so I think this is really especially important for newcomers when somebody and you come to Rails, they only have to learn one way of creating HTML tags. And I think it's also easier to remember. Now still talking about helpers and views. The next one is I think probably a question that everybody who has ever programmed in Rails has wondered. When you want to create a form, why are there two helpers? Why is there form four and form tag? Sure, they do different things and one accepts a model but it looks so similar that sometimes it's confusing. So what's going to change in 5.1 is that instead of having two helpers to create a form, you have three helpers. There is a new form with. Now the good thing is that this is one to rule them all. So in the long run, the idea is that you're going to switch to form with and then only form with will survive. And for now, nothing has been deprecated. So it's just there. If you create a brand new scaffold app with 5.1, it's going to use form with but for now you can use all of them. So let me just show you how you can upgrade syntax from form four and form tag to form with. If you're using form four, in this case, I'm showing a form to delete a post. You can still do it with form with you have to say actually model post so you have to pass it like that. It just basically syntax difference. If you use form tag, then the first argument is the URL you want to submit to. And with form with you have to specifically say form with URL. Other changes here, for instance, in 5.1, if you create a brand new app form with is going to be remote by default. And also what's pretty interesting is that form with, if you have a block has this F all the time and form tag does not. So with form with you can actually mix the different helpers like submit tag or F dot submit you have the chance to do that. And I think in the end it's going to be less confusing. Okay. I'm think halfway through the list of features. And I think the reason why I made this stock is also really to invite you all to look at the source code and then up for of course upgrade your rates application to 5.1. And also, as my personal way to thank all the people that are mentioned in this slides, the creators of all this for requested contributors. So now let's continue with real ties. The first one is, if you use, if you are in your terminal, you can type rails initializers, and that is going to print out all the initializers of your app. Now the problem is that in 5.0, it's only printing out the method name, and different classes can be using the same method name and you can't really tell. In race 5.1, it's going to output the name of the class and the name of the method. So it's less confusing. And it's more useful, especially if you use race engines, you can just see clearly the order in which they are called. Now let's talk about secrets. Every Rails app has a file config slash secrets.yaml where you can store your secrets, meaning your API keys or any other variable that you want to define once for your environment, your settings, or maybe your email address that you want to use. So there is this secrets.yaml file. And maybe when I'm developing, I want to send all my emails from a specific email address and also when I'm testing, but now when I'm in production. So how do you share one of these variables among different environments? For instance, I want to set my email from to that specific address in development and maybe reuse it in tests. In 5.0, you can already do that. You just have to use this yaml syntax. The ampersand and then remember, like, how, I mean, it's really yaml syntax, but you just have to remember that you have to define the default and then say development, it's using the default. 5.1 is just a little simpler. If you have a section with the name shared, it means that everything that is in that section is going to be available to any environment. So it just makes your code shorter and more readable. This is just one of the changes to the secrets, but there is another one, which is even more important. And that is the addition of encrypted secrets. So as I said before, in this secrets yaml, you can store your secrets, but you probably don't want to store your real production secrets in a plain text file. You don't want to put there your PayPal account information or your API key in production because otherwise everybody who has access just to the source code can be able to access your PayPal and email and everything. So you don't want to put them in plain text right there. As a matter of fact, if you look inside these secrets or yaml, there is a disclaimer and is a comment that says do not keep production secrets in the repository. Instead, read values from the environment. So it is right there. So this is a good advice. But sometimes you need to access your production secrets. You need to install it on a new server or maybe share them with a co-worker. So how do you balance this? How do you balance this? Of having the secrets available, but not in plain text for everybody. This is a new feature of Rails 5.1 and it's encrypted secrets. The way in which it works is that you type Rails secrets set up and this is going to generate two new files. So you can use config secrets yaml.key and config secrets yaml.enc which stands for encrypted. Now the encrypted file is where the secrets are. But if you just try to read this file, you're not going to be able to read them. They're encrypted. In order to open this file, you need to type Rails secrets edit. And this is going to use the key, so the other file, to open it in your editor. Then you can edit, save, and as soon as you close your editor, they're going to be saved encrypted once again. So in short, if you want to read them and edit them, you need both files. But if you just have the encrypted files, then it's okay. You can put that in your repository because people are not going to be able to decrypt them. So the solution is you can put your encrypted files in the repository and you can put it on GitHub and share it. But don't put the key, otherwise this is useless. So keep the key to yourself, share with your coworkers, maybe with a password manager, and then on your server, and then you can have the best of both worlds. You can have encrypted keys. So maybe when you create a new machine, you don't have to manually set 100 environment variables. You just need the key. But then they're encrypted. So if this works for you, it's right there for free in Rails 5.1. If you want to keep on using the other approach of just setting variables in the server, you can still do that. Okay, still talking about Rails.js. Rails.js has seen a lot of great features. jQuery is not a required dependency of Rails anymore, meaning if you don't need it, it's not there. This doesn't mean that we don't like jQuery. I like jQuery. But if it, you know, it's one less library if you don't need it. Let me take a step back. Why was jQuery there in the first place? The main reason was what is called UJS, Unobtrusive JavaScript, and it's for features like this. This is a still arrays scaffold. So you have your list of posts, and for each post you have these links. One of them is destroy. So it's a link to destroy one of your posts. What happens if you click on that link is you're going to see this. You're going to see an alert. This is not the default for links in a browser. Links just work. So it's the JavaScript that it's intercepting your call and showing an alert. And also there is something else here. Normally links cannot do a post or a delete to your server. They just get. So how does this work? It's because there is this UJS that it's looking at the attributes of your link, the data confirm data method, and it's changing things there. So all these came from the jQuery UJS library, which is just JavaScript that has all these features. It looks for these attributes and it changes. There's also data disabled with data remote and so on. Now, if you think about it, you can write the same JavaScript in vanilla JavaScript without jQuery. And that's exactly what happened. A student from the Google Summer of Code of last year for Rails has done this, has rewritten the jQuery UJS library without jQuery. It's now called Rails UJS. It's inside action view. So if you want the exact same features, all you have to do is just require Rails UJS. You don't need to add gems to your gem file. You don't need to require jQuery. It's a smaller footprint and it's exactly the same behavior. Okay, I think I'm going to now get closer to the features you probably have heard of, or maybe that's why you're here in the first place. And I think this is one of them. The original title of this PR was add yarn support in your apps using the dash dash yarn option. I deleted that because since this PR, this has changed. So now it's by default. You don't even need to do dash dash yarn. So whenever you're going to do Rails new with Rails 5.1, you're going to have yarn support. Now let me take a step back. What is yarn? If you are front end developers, you probably have heard of it. It's a package manager for assets or JavaScript libraries. Think of it as bundler and gem file. They are for Ruby gems. Well, if you need to bundle a bunch of JavaScript libraries, yarn is one of the possible solution. And this is really where the Rails team didn't need to reinvent the wheel and create a new one. Yarn has been accepted in the last year as one of the good options. And now it ships with Rails 5.1. So this solves the problem of how can you import a lot of JavaScript libraries in your Rails app? Of course, you could already do that before. You can just copy and paste them in your vendor asset folder. But if it's like one or two, you can manage that. But if you have tens of them, and maybe you need to, if they have dependencies or you need to upgrade them, it becomes complicated. So that's what happens with yarn. Let me show you how you would use yarn with 5.0. And then let me show you what changes in 5.1. In 5.0, you need to install yarn, and then you do yarn init, which sets up the folder. Then you start adding your libraries, for example, bootstrap. These libraries are installed in a folder called node modules. So then you want to ignore this folder, and you have to do that. And also, you have to add this folder to the asset pipeline. And finally, you can just require your libraries. So from 5.0 to 5.1, this happens. There is less setup. There is more convention over configuration. So they're going to be installed in node modules. That folder is already getting ignored. It's already in your pipeline. So it's just very straightforward. And this is leveraging the power of yarn. You can do much more. But this is just really introducing it to the Rails community, and I think it's going to be a great change. Now, you might want to use yarn if you are including, for instance, third-party JavaScript libraries. But what if you are writing JavaScript? What if your app has a lot of JavaScript? Maybe you're using Rails, but then you're writing a single-page app, and you have it all at once. You might start having questions like, in which folder do I put my files? How can I use ES6? How is it going to be pre-compiled? Things like that. So for this, there is another feature in Rails 5.1 that can help you. And that is the fact that you can now leverage Webpacker. So what this means is that there are different ways to structure your JavaScript, let's say, single-page app, and different libraries that you can use. And now with Rails 5.1, you have, once again, a sort of convention over configuration. You have some pretty good defaults. If you do Rails new app dash dash Webpack, a lot of files and folders are going to be created for you. There's going to be an app slash JavaScript folder where you're expected to have your JavaScript in packs. There is a lot of configuration that is written for you in config slash Webpack, and it's separated by environment, development and production. There are some libraries that are there already for you that you're probably going to need, like Webpacker, and Webpacker, and Webpacker, and Webpacker to use Webpacker, Webpacker is available, or, you know, Coffee, SAS files are already ignored, and then there are some bin files, Webpack, WebServer, Webpack, Watcher, and Webpacker. So all this is there for you. In the past if you had to use Webpack with Rails, you had to install it and then decide that I had to do some configuration and stuff, Locally, you can type Webpack Dev Server, which is one of those new commands that come with it. And this is going to watch your folder, your app JavaScript. And as you type, even if it's your six, it's going to watch that folder and then make it available for you so you can develop and have those JavaScript available in your app. The way in which you include those in your app is with this new helper JavaScript pack tag, where you specify which pack you want to load. And if you also have style sheets, you have style sheet pack tag. And there are many, many other features. For instance, you can interpolate Ruby. You can use, you know, a Routes helper. So you just do application.js.erb. There is really a lot that I cannot cover, but all of this is powered by a new jam called Webpacker. And it's open source. It's available on GitHub, Rails slash Webpacker. So feel free to go there and look at what's happening there. Also, this, for instance, works right away if you want to deploy on Heroku or the precompilation. And the last thing I want to mention is that when you do Rails new dash dash Webpack, you can specify as an option, React, View or Angular, which is going to install and configure more libraries for you. So if you need to use TypeScript or JSX, it's all there for you. Okay, I'm going to talk about Action Pack last. If you go and download my slides, I have more slides about Action Mailer and ActiveJob that I'm not going to be able to touch here. But let me just talk about Action Pack. The first feature is actually a mix between Action Pack and Railties, Cappy Bar Integration with Rails, also known as System Test. If you were in this room yesterday, you saw an amazing talk by Eileen Ishitel, who created this PR, and she spent 40 minutes on this feature. I'm just going to try to summarize in two minutes, but you should probably go and re-watch her talk on YouTube. So in summary, System Test, I'm still making an example with Skaffold. If you have a Skaffold, an example of System Test is when I go to the page slash post, I actually want to ensure that in the browser, in the header H1, the text says exactly post. Like I want to test exactly the final result in the browser, not just a unit test. So how do you write this sort of test? In Rails 5.0, you have to make a decision which library I'm going to use, which version, how to install it. As an example, you can decide that to your Gemfire, you're going to add Cappy Bar and Selenium WebDriver. Then before you run your test, you have to require those libraries. Then you have to write a lot of configuration. This is just a very small example. Like you're going to say that Cappy Bar is going to be driven by Selenium. You're going to use Chrome. You might specify a resolution. And then after you do all of these, you can write the test. Now, the test itself is not super complicated. It has basically two lines. You visit slash post, and then you assert that inside the H1, the text is what you expect. So it's really about making everything else go away and focus right in the test. So in Rails 5.1, forget about the setup. All you have to do is write your test. Your test is going to inherit from a class called application system test case, which is going to set up all that for you. You can also use route helpers like post underscore URL. And then you're going to write your system test with Rails test system. So much more convenient. And also it has great new features like screenshots that are taken if your test fail, clean the database. And one more thing is that the old type of functional controller test are not going to be generated anymore when you have a new 5.1 app. You're going to see this type of test. The other ones are still going to be running for backward compatibility. And I'm going to talk about the last feature in Action Pack, which is, I guess, my favorite one. And this is one example of a PR that it's a single PR, but it's like five features in a single PR. And in short, it's adding two new methods that you can use in your config routes. But these methods are very powerful. They're called direct and resolve. And I'm just going to go through two examples that show what they do. But once again, go and check the code because they can do much more. The first one, still a scaffold. This is a post page. And then imagine that below the post, you have comments. So each comment does not live on its own page, like slash comments slash one, it lives inside the post page. Now, imagine that you want to link to one of these comments. How do you write that code? It's not that it's hard to write the code in 5.0, for instance, you can say, link to comment number two, post path, because the page is the post page. So you do post path and then you say anchor content two, because you're basically linking to the post page at a specific place in that. But I believe that all this logic should belong to the routes, not to the view. When you do a link, you just want to say I'm linking to some embedded content. And then the routes are, you know, it's the responsibility of the routes to route. So to say, oh, it's a link to a comment, but the comment is actually, you know, inside the post at a certain anchor. So this new direct method, let's you do that. Let's you define once in your routes this style of routes. And then your views can just be used with link to super simple. So it's very powerful, especially this might sound like a kind of simple example, but you have if you have more polymorphic resources, this can help a lot. The other new method solves several problems. And one of these problems is if you have a form that's that post to a singular resource. For instance, if you have a form that lets user update their profile or create a profile, a user has one profile, not many. So you might want to do a form that submits to slash profile singular. Now, if you try to do this just by doing form for at profile in Rails until five point zero, you would see an error. It's saying undefined method profiles path plural because by default, all the routes are plural, even though you say resource singular in your routes file. There is a work around for this, but this has actually been an issue in the GitHub in the rails GitHub since 2011. People have been asking why is it like this? Can we just make it, you know, work just work. So in five point zero, the work around was when you do form for at profile, you have to specify the URL. You're saying, yes, it's a form to a singular profile, but I have to explicitly say this is my URL. And if you have a form to update, you have to do it. If you have a form to destroy, you have to do it. You have to do multiple times. In five point one, you can add this resolve profile, which is the name of the class as a string and then profile. You just do that once. And then it's that one is basically saying the routes for a single profile. It's basically just going to work. And you do that once and you do that in your routes file, which is probably where you should do it. And we that I have one minute left. So I'm just going to leave it here, but feel free to go and look at more features there. And also feel free to go and look at the changelog files inside the libraries. And then once five point one ships, there's also going to be a guide to upgrade your apps from five point zero to five point one. And I just want to thank all the people who have contributed to Rails and all the people here who are going to maybe start contributing to Rails. And that's what I have. Thank you very much.
release of the framework that we all love and that I have cats in this talk, so I'm going to development, it's using the default. 5.1 is just and more readable. This is just one of the addition of encrypted secrets. So as I said new feature of Rails 5.1 and it's encrypted Unobtrusive JavaScript, and it's for features these came from the jQuery UJS library, which is wheel and create a new one. Yarn has been include those in your app is with this new helper write this sort of test? In Rails 5.0, you have test with Rails test system. So much more going to be a guide to upgrade your apps from