 and 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 may wanna go there simply because there are links to the pull request that I'm gonna 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 with you with open source. To give you a little bit of context, 5.1 is gonna 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. 5.1, you can think of it as 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 gonna 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 Rubicop for styling, so you're gonna see many things like spaces, single quotes, double quotes, but that is not really gonna affect you as users of Rails. So that is what I'm gonna talk about today. If you use Rails, how is this new version gonna affect you? And so what I'm gonna talk about is breaking changes than active record, active support, action view, rail ties, and action pack. And so the last disclaimer before starting is that I have cats in this talk, so I'm gonna 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 gonna talk about, but they are not that big. I'm gonna 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 gonna affect you at all because the result is the same. This is only gonna 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 wanna look at this. Otherwise, it just a benefit for you. It's gonna be faster. The next one is when you 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 wanna set no title, that unless you could pass a string in 50, 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 gonna be able to use a string anymore. But you can still use a proc, you can still use a symbol. So if you're using strings for those conditions, then you might wanna change to this new syntax. Still talking about breaking changes, this affects your config routes. So when you set your routes, you're also gonna use strings. You're gonna 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 or slash column action or slash column ID. So this kind of syntax was valid until race five and these are wildcards. 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. But the decision was made so that going forward, this syntax would not be acceptable anymore. Instead, if you have many controllers or actions, you might wanna whitelist them explicitly, which I also think makes for better and cleaner code. So 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 gonna be hard for you to upgrade to Rails 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 a big int or a big serial if you're in Postgres. So you basically have 64 bit. So if you need to reference many records in database, now this is the default. You just have begin as your primary keys. This can be useful. And still talking about databases, this is only for MySQL or equivalent MariaDB. There is now support for virtual columns. I also, I'm gonna 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. MySQL lets you do that with this upper name in SQL. So basically SQL has this virtual column which is not like a duplicate it's just calculating the uppercase version. And now you can reference this column in your migration by writing plain Ruby. You just do t.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 MySQL to store this column and also to index by this column. So if you wanna display your users sorted by the number of characters, you know MySQL can do all of this and this is the code you need. And what is good about this is that you don't have to write your structure.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, ActiveRecord provides methods to do this like find each or in batches. So if you wanted to iterate 5,000 posts you wanna 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 the limit 500.pn each, you would actually get a warning saying scoped order and limit are ignored. And so the query would just fetch 1,000 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, I'm gonna get to the end where you're probably gonna see the features that have made the news or that other presenters are talking about here. But let's continue with active support. There's now support for Unicode 9 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. And 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 9 and families are not gonna be separated anymore. Active support duration has two methods called since and until and now they have aliases after and before. This is also 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 in 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. Okay, let's get to one of the sort of bigger requests. There's a new method in a module called delegate misinter. I think this is gonna 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 a couple. Then this can help you. Let me show you how. I made another example here. Imagine you have an order active record in ordering 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 wanna delegate. So it might not be your first choice. Another way to do this is to use Ruby's metaprogramming methods. You can define 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 does exactly what I explained. So if you're gonna call a method on order completion and the method does not exist there, then it's gonna 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 a very interesting one. The first one is how do you output an HTML tag with Ruby? You actually have in Rails, you actually have two helpers. There is one helper called tag and there is one helper called content tag. If you wanna output a tag like br, a breaking line, a way to do it in Rails is tag br nil 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 it's self-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 five one, 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. So it's basically tag dot and then the HTML tag and you don't have to remember the order of the arguments. And so I think this is really especially important for newcomers when somebody new comes 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 wanna create a form, why are there two helpers? Why is there form four and form tag? Sure, they do different thing and one accepts a model but it looks so similar that sometimes it's confusing. So what's gonna change in five point one is that instead of having two helpers to create a form, you have three helpers. There is a new form width. Now the good thing is that this is one to rule them all. So in the long run, the idea is that you're gonna switch to form width and then only form width will survive. But for now nothing has been deprecated. So it's just there. If you create a brand new scaffold app with five one, it's gonna use a form width 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 width. 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 width, 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 width, you have to specifically say form width URL. There are other changes here. For instance, in five point one, if you create a brand new app, form width is gonna be remote by default. And also what's pretty interesting is that form width, if you have a block, it has this F all the time and form tag does not. So with form width, 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 gonna be less confusing. Okay, I'm think halfway through the list of features. And I think the reason why I made this talk is also really to invite you all to look at the source code and then of course upgrade your rates application to five point one. And also as my personal way to thank all the people that are mentioned in these slides, the creators of all these requests and the contributors. So now let's continue with real ties. The first one is if you are in your terminal, you can type Rails initializers and that is gonna print out all the initializers of your app. Now the problem is that in five point zero, 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 five point one, it's gonna 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 Rails 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 wanna define once for your environment, your settings or maybe your email address that you wanna 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 test. In five point zero, you can already do that. You just have to use this yaml syntax, the ampersand and then remember like, 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. And five point one is just a little simpler. If you have a section with the name shared, it means that everything that is in that section is gonna 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 these secrets yaml, you can store your secrets, but you probably don't wanna store your real production secrets in a plain text file. You don't wanna 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 wanna put them in plain text right there. As a matter of fact, if you look inside these secrets yaml, there is a disclaimer as 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 coworker. So 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 setup, and this is gonna generate two new files, 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 gonna be able to read them, they're encrypted. In order to open this file, you need to type Rails secrets edit, and this is gonna 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 gonna be saved encrypted once again. So in short, if you wanna 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 gonna 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 wanna keep on using the other approach of just setting variables in the server, you can still do that. Okay, still talking about Rails 5.0, Rails 5.0 has seen a lot of great features. jQuery is not 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 it's one less library if you don't need it. So let me take a step back. Why was jQuery there in the first place? The main reason was what is called a 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 gonna see this, you're gonna 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 gonna 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 new apps using the dash dash yarn option. I've 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 gonna do Rails new with Rails 5.1, you're gonna 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 wanna 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 gonna 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 race community and I think it's gonna be a great change. Now, you might wanna 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? Is it, how is it gonna be pre-compiled or things like that? So for this, there's another feature in race 5.1 that can help you. And that is the fact that you can now leverage webpacker. Webpacker. Webpack. So what this means is that there are different ways to structure your JavaScripts, let's say a single page app and different libraries that you can use. And now with race 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 gonna be created for you. There's gonna 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. They're probably gonna need like Babel or Coffee, SAS files are already ignored. And then there are some bin file, webpack depth server, webpack watcher and webpack. 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 I have to do some configuration and stuff. Now it's all there for you. So once you've installed it, the way in which you use it, locally you can type webpack depth server, which is one of those new commands that come with it. And this is gonna watch your folder, your app JavaScript. And as you type, even if it's your six, it's gonna 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 wanna 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, about helpers, 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 wanna deploy on Heroku or the pre-compilation. And the last thing I wanna mention is that when you do Rails new dash dash webpack, you can specify as an option, react, view, or Angular, which is gonna 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 gonna talk about action pack last. If you go and download my slides, I have more slides about ActionMailer and ActiveJob that I'm not gonna be able to touch here, but let me just talk about ActionPack. The first feature is actually a mix between ActionPack and Railties, Kappi Bar integration with Rails, also known as SystemTest. 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 gonna try to summarize in two minutes, but you should probably go and re-watch her talk on YouTube. So in summary, SystemTest, I'm still making an example with scaffold. If you have a scaffold, an example of SystemTest is when I go to the page slash post, I actually wanna ensure that in the browser, in the header H1, the text says exactly post. Like I wanna test exactly the final result in the browser, not just the unit test. So how do you write this sort of test? In Rails 5.0, you have to make a decision. Which library am I gonna use? Which version? How do I install it? As an example, you can decide that to your gem file, you're gonna add Kappi Bar and Selenium WebDriver. Then before you run your tests, 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 gonna say that Kappi Bar is gonna be driven by Selenium. You're gonna 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 DH1, 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 gonna inherit from a class called application system test case, which is gonna set up all that for you. You can also use route helpers like post underscore URL. And then you're gonna 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 tests fail, clean the database. And one more thing is that the old type of functional controller test are not gonna be generated anymore when you have a new 5.1 app. You're gonna see this type of test. The other ones are still gonna be running for backward compatibility. And I'm gonna 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 gonna go through two examples that show what they do. But once again, go and check the code cause 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 wanna 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 wanna say, I'm linking to some embedded content. And then the routes are, 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 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, the views will 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 wanna do a form that submits to slash profile, singular. Now, if you try to do this just by doing form for ad profile in Rails until Rails 5.0, 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 workaround 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't we just make it work, just work? So in 5.0, the workaround was, when you do form for ad 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 it multiple times. In 5.1, 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 that one is basically saying the routes for a single profile, it's basically just gonna work. And you do that once, and you do that in your routes file, which is probably where you should do it. And with that, I have one minute left, so I'm just gonna 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 5.1 ships, there's also gonna be a guide to upgrade your apps from 5.0 to 5.1. And I just wanna thank all the people who have contributed to Rails, and all the people here who are gonna maybe start contributing to Rails. And that's all I have. Thank you very much.