×
Eventil - Find Tech Events
Official mobile app
FREE - In Google Play
View
×
Eventil
Official mobile app
FREE - In App Store
View

Why should I care about Rails 4?

0 0

already a good morning everybody thanks for showing up bright and early after the party last night I had to like you know make sure to pay attention to you know what I'm like I cannot drink too much and stay out until 4am the night before giving a talk so the the title of my talk is why should I care about rails 4 and it's sort of a talk about rails and talked about like the future of web development of where it's going a little bit as well at the end so I'm Steve by the way if you don't know who i am if you're not from the Ruby world we've never seen me talk before uh basically like the reason I'm talking about rails 4 is I've been doing a lot of work to get it out the door so I'm now number 66 contributor to rails all time which is kind of cool and exciting I do work with jumpstart lab we do the best Ruby and rails training classes on earth so if you want to get better at ruby rails you should call us and jeff and myself for Katrina or some new people we've hired will show up and level you up at your Ruby and or rails so it's a lot of fun i really really enjoy teaching people it's it's a blast and i could travel over the place so unfortunately i only have half an hour and there's actually tons of stuff this is a little small i guess but this says so seven over 7,000 commits since 3282 master and over 2,000 files changed and we've had 46 different authors contribute to rails for so that's super fantastic right like we can't to one of the one of the good things that like you know Charlie was talking about in his last talk was how it's a community of people right and so you have a lot of people working on projects so you know even though we talk we have like rails core there have been 50 people who've contributed to the rails 44 explicitly alone so since this is Rupa I wanted to like make this talk interesting for people who are not primarily rubyists as sort of you know all of us are trying to bridge the gap I actually really like Python I tried it before Ruby I just Ruby fits my brain better so I prefer it but I would much rather program in python the most other languages so this is going to be like features for rubios that you will enjoy in rails 4 and features if you're a Python Easter you can make fun of rails people for them being added to rails because they're bad so i will be showing you some great features and some bad features you know in my opinion anyway about what features are good and bad so so that's this what you want to pay attention to if depending on who you are so because I like positive let's start off with a rubios so like what's what's super awesome in rails for the first thing is that we're only supporting Ruby 193 and of course Ruby 20 when it comes out but we are not supporting Ruby 18 at all and we're not supporting ruby versions before 193 this simplifies a lot of things because we don't have to keep a lot of code paths around that we're like patching things that were different between 18 19 Ruby 19 is a lot faster and you know if you're going to upgrade you should be on Ruby 19 by now and I think that this will help get a lot of older people forward you know Ruby 19 is a good Ruby even though I do have a special place in my heart for JRuby and Rubinius both as well and we you know try to support them you know as much as possible but 193 is the official Ruby compatibility version as being supported my favorite feature about rails for actually is the is how much stuff we're removing so the the biggest thing is all these things so like page in action caching rat cash observers the end sweepers session stores mass assignment and active resource are all being pulled out into gems and so rails 4 will depend on them so you'll still get them in rails for itself but in rails for one will be removing that dependency and so if you want to use these features you can add them yourself so I think that it's really important that as time goes on we remove features that don't make a lot of sense for everyone anymore you know as things change I've never seen code with observers that I thought was good code for example right but they've been around in rails for a long time so it's time for them to go that's one of the ones i was working on was taking observers out so I and we still want to support people that are using these features though so these these plugins will be maintained by the rails core team until the release of rails 5 so not going anywhere anytime soon but if you don't use these features you won't have to worry about that code being in your in rails any more specifically also by divorcing these projects and rails the people who do use them and do think they're a good idea can improve them without having to wait on the rails people so like active resource is sort of stagnated for a time because nobody in rails core uses them and since it's been a plug-in a group of people that use it all the time they've actually contributed a bunch of features and it's been improving in a relatively rapid pace so even though I hate active resource and think it's a terrible idea those of you who think it's a great idea can like you know not wait on people merging stuff with rails core so I think this is like a great move for everyone I loved if swear code gets removed right so from the rails core this is all this is all diffs of removal so one of the things is being removed as mass assignment so if you you know pay attention to all the the hubble hubble ooh around the mass assignment issue we sort of fixed it in rails three two one by making use at are accessible and you had to turn math assignment back on so that needed to happen immediately so that you know we could like fix the security issues but it wasn't really the right way of doing things and so rails 4 is going to be introducing strong parameters all the features that i mentioning that are new by the way almost all of them are gems that you can install currently in your rails three apps so if you want to use these features it's sort of the reverse of my last thing like you can put these in your rails 3 app and use them so you can do this today if you'd like so strong parameters changes the way that masses I'm it works so you don't declare things as assignable in the model anymore security is all handled by the controller so in this case we have a people controller and if you use person to create params person it would throw this active model forbidden attributes exception and so the way that you do it is by using this little dsl you can see down at the bottom where you say require and permit so this like whitelist and blacklist attributions a couple other things involved with this dsl most people were using this pattern that i'm showing where you pull the parameters like out into a helper method and this says like what your security is so that it's in one place this has a lot of other nicer sort of effects too so not only is it sort of the securities in the right place like I think that this is a better way of handling this kind of security it means that a lot of a lot of things that used to do like logic on models in your models had to deal with the security issue need to get around it so we have all of our tutorials online for jumpstart all our curriculum and after the whitelist attributes thing hit I had to go back and change a lot of our code because we had so for example on a blog where you have tags for your blog posts right there's this big join between like tags and taggings and blog posts to do the many-to-many so when you have this white listing of attributes you could no longer use the really nice like just build on my tags here to go through and assign stuff and made that code really ugly and if I'm already in my model layer I don't care about the security of the parameters right like the issue is people submitting forms which is a controller issues so i think is a much better separation of concerns it leads you to like have nicer code a lot of people have said in like tests their tests are nicer now because they don't have to worry about this assignment stuff and tests so this is one of the big changes that i think is really useful my favorite feature one of my favorite features of like every feature is my favorite feature at different times they have been rails queuing sort of started off as a joke and now it's kind of a serious thing so uh yeah basically the idea is that we have a unified q interface for anybody who wants to use queues so if you have used rails cash before for example you can swap out memcached or Redis or whatever story you want this is the same idea but with queues so in this case you need any class that that responds to a run method and then you can do rails queued up push job and it will go on a background queue in a test environment or in a development environment by default this will use an in-memory Q so it'll just use Ruby's queue and it'll spin off the thread and do that to do the work and then in production you'll be able to install an adapter for whatever one you want so I help maintain rescue and we have a rescue rails adapter that will make this work and sidekick already has an implementation to of this Q interface so you would just install the regular gem and now none of your code changes in production or you know development and you get to use the production cumin production and in-memory queue and development and it's all nice this is cool because almost every serious app has a job queue of some kind and it's sort of annoying to have to set up like this is the first feature that's always a pain like I I try to put it off because I don't want to bother installing Redis and getting rescue running even though I help maintain it right I was like I don't want as many moving parts as possible so this lets you get away with using this in memory queue to develop stuff all the time and just not have to worry about the production issue until you're ready to actually deploy you know which can be months down the later on a greenfield project one nice thing about this too is that you get mailers that are asynchronous for free so like by default any action mailer that you send will now happen in the background in that job queue you don't have to do anything special your emails are no longer in process this is kind of neat you can change the queue that you want by using this class attribute so you can just set the queue to a particular kind of cue and make it work but I'm just transparently behind-the-scenes your mailers now happen the background so I think that's kind of neat and that's what happens with this uniform interface that we're allowed to like have these adapters sort of systems action controller live is kind of neat so Aaron Patterson has been doing a lot of work on streaming so you get this you can include action controller live and you get this response dot stream object that sort of quacks like an i/o so you can write to it and then close it so this will extreme information to your client you can do like server-side events so this kind of thing and that sort of stuff and it's it's a neat feature declarative etags so rails has always had pretty reasonable support for HTTP stuff built in but now you can say like I would like this to have an e-tag based on something so in this case we're saying the ID of the current user and then when we say fresh when on the invoice it will use that etag and it will change based on whatever users involved so you can have like caching for if not match his microphones dying Oh stay farther away from the cool I'm like getting up in here so so yeah so this like sort of declarative syntax let us say like right at the top of the controller this is what I want my freshness to be based off of instead of having to mess with it in each individual action so it's kind of nice etags are really good caching HTTP caching is awesome so sprockets right the feature that everyone loves to hate I think the asset pipeline is amazing but its implementation is kind of crap right so like I'm really glad that it exists but I'm really not glad whenever it fails really poorly so it's actually been sort of rewritten and pulled out so now we have this sprockets rails instead of sprockets being built into rails itself and there's been a lot of work done to make it faster so this is one benchmark that was run doing rake assets precompile and it's like eight seconds and the old sprockets and one second on the new sprockets so there's a bunch of shenanigans going on in there to make these things faster but you should basically just see a transparent speed-up of your asset compilation with the asset pipeline so that's kind of cool the HTTP patch method was added right now it's just a really simplistic implementation where you can accept I guess I did a post instead of a put on the slide the slide is wrong patch or put will both redirect to the update action by default and if you want you can also use all the routing dsl's and everything else like where you would based in HTTP method now has patch as well as well so if you want to use that in your app so like github uses this for the API for example you can use HTTP patch so it's kind of nice there's been some questions what's up they both go to the update method you would it so like the default thing is like this is like the first step to getting it in this was like the biggest bike shed argument that's happened in like a long time on the rails issues thing so people basically wanted like a minimum path that people can start using patch if they want and so I don't remember if forms now use passions that have put by default anymore is there like method override thing or not but you shouldn't the point is to update whatever thing it is you shouldn't care which method it is sort of the view of this thing we can get in this later i have like a bunch of slides and we'll see if we have any time at the end but basically I they're synonyms at the moment and this will open the door to future stuff hopefully so there's been a lot of talk about like rails versioning and you who to describe it is like a shifted sem verso rails does not follow semantic versioning but here's sort of the way it's going to work out in the near future so the idea is that four-point-oh will be an easy upgrade it should be as drop-in as possible and you should not like this will not be the two to three transition by any means ideally there will be no next to no back-breaking changes of course unless you like rely on bug behavior or something which some people do and there won't be any new deprecation Xand point releases from this step forward so there are some situations with the 3-2 series where we were deprecating things and minor patch releases and that was making people mad and rightfully so so we're now only deprecating things in like the you know XYZ we're not doing it in the Z patch levels only in the Y patch levels and so everything is going to be introduced the new features in 40 and throw warnings if you use things that are going to be removed and then they'll be removed in 41 so this sort happened with a 30 release too but we're like committing to making it drop in and not removing stuff in if at all possible so that's the stuff that's cool now let's talk about the stuff that I don't really like first on the block is routing concerns so this is kind of like this macro system by which you can you know dry up your house this originally was implemented is like splitting your routes into a ton of different files and then having the router load the files but then it was like determined that having 15 different routes files with 10 lines in them is basically worse than having one lot of one file with like you know 100 lines in it or whatever so this is sort of this macro system by which you can say like if I have you know resources that have sub resources of comments and I have them on three of them then I can just determine this like trait or this concern that says like comment about resources have comments on them and then i can say like oh all three of these resources have this concern on it i don't particularly think that this improves any sort of readability whatsoever but other people do and so it's in there we'll talk more about that later there's going to be a nap models concerns directory uh this isn't for the first like image photo that came up for concerned and I thought it was awesome I'm really concerned about how much we're taking concerns and adding them to rails so the new party line for how to like fat model skinny controller right like so everyone is sort of understanding that fat model is kind of bad at this point and so the new party line about how to split up your fat models is to break them out into 15 active support concerns instead of having one user class that has like four hundred lines you have one user class that includes 15 modules and then 15 files that go over if you know we just determined that that was bad with routing but that's good for models somehow I'm not really sure how that works but so this is going to be a new directory that we will see to being generated one of the funny things is that get doesn't track empty directories so if we want to actually make this like be generated by default we have to come up with a default concern to put in the directory because then get won't recognize it so it won't be in your repo anyway even if we generate it yeah so we like in that just it's just ridiculous so there's that cash digests is the official name for the Russian doll caching you may have seen David talking about and this is kind of cool I have bigger problems that this is more about the rhetoric involved about javascript in the rails world which we'll talk about in a minute but basically you can do this caching block so you say like I'd like to cash a project due and then everything in the block has a cache key that's generated based on that object so when the object changes it changes the cache key and it will always use the newest one and these things nest so if the project has comments on them and use a comment block on the inside if the comment changes that will invalidate the parent project cash as well so this isn't necessarily a terrible feature but it's kind of problematic for other reasons you may have seen this new feature that got added to rails turbo links so this is a gem that's being included in the gem file by default from now on basically what happens is it's sort of like P Jax but less complicated so the idea is that you you fetch the whole page with Ajax overrides all links to fetch them with Ajax and replaces the body element in the title element instead of doing a whole new page load the only thing that it's almost drop in supposedly except for the fact that you need to bind to this page change event instead of document ready because document ready doesn't fire because we're not loading new pages and you can use data no turbo link to override that on any particular link there is something like like 40 open github issues I think at the moment and there have been like 120 since this was introduced so I think the idea of promoting it as drop-in is core to sort of dangerous because it's not really dangerous or it could be dangerous and you just like sort of won't know but it gives us max speed so it's good to add by default to everyone's apps regardless if they want it or not so that's happening in rails for I actually did so people were talking about the differences between P Jackson this in terms of performance and it actually is faster it's faster in many cases I have a github repo where you can see a benchmark and you run selenium tests for yourself and see the difference and if it makes sense for your app but it's it may be useful for some apps but I don't think it's a good general default this is sort of a good change but it's sort of also examples like bike shedding and arguments about how rubios skin and like pretty arguments so active record base all will no longer return an array of elements it will just return itself in a relation you need to call to a to return an array of elements this like simplify some syntax and make look more like everything else but it's just it's just kind of silly mr. minor change but it might bite you for some reason so this is security instance so if you ever used match to match a controller in an action all HTTP verbs will respond to that which could introduce you to the attack surface your application is larger so you should be using get instead of match so we'll be throwing errors if you use match without defining verbs so match is intended to be used if you wanted to match multiple verbs not to just as a sin didn't forget so this is like a security thing so I think it's good but it's sort of dumb that we did this in the first place and I can't really believe that this was like implemented that way so okay so that's like the bad part of things the big question then on everybody's mind is when is it going to be released and I have for you a certified sanctioned dhh approved answer which is when it's ready he also said that he hopes that is ready by the end of the year so that's sort of our informal target but we're not going to release it until it's actually done there's sort of a couple things that are blocking the release the people were working on there's some security other security things that are being added and a couple changes the queuing interface that we're going to work on internally for the adapters not for you using it so it's close but it's been closed for like two months now so you know when it's done it's done it's not blocked on turbo links that's that's going right in this up done fixing oh yeah so look at Ruby quote rails core there's a bit to the thread about that right now it's good so the I was thinking about like the title of this topic and in general so I always like to do broad stuff as well like you can read the changelog and see all these things so part of the reason why you wanna hear me talk about this stuff is for perspective right so I was thinking about the question like why should I care about rails 4 and this is a subset of the question like why should I care about rails right and you know we have lots of our web frameworks and Ruby's so like why do we keep using rails all the time and like what is it about rails that that we care about I I have joked I think this is someone else's quote but I can't find an attribution for it so maybe I just don't want to be held responsible for saying this but like so rails is the best web framework 2005 has to offer right like rails has changed a lot and it's improved a lot but it's still fundamentally the exact same thing is like the the 15-minute blog do is still understandable to us today right like that looks like rails and so we talked about how awesome it is that rails was extracted from base camp right like this isn't an intellectual ivory tower framework it's all of its stuff is all the things that features and rails are derived from real use cases from real production applications but this sort of this sort of made me wonder like what happens if you're not building base camp though right like it's great if rails is tailored to build base camp but lots of people are not building base camp so Israel still good for those people and this sort of gets into this JavaScript question about the future of JavaScript and rails apps so dhh mentioned on his blog that like they don't do anything but a couple selenium tests for their JavaScript and this sort of reminds me of what we when we talk trash on PHP people back in the day of like oh you don't test any of your applications we run tons of tests and ruby but now like because it's JavaScript it's acceptable to like not have a good testing solution for some reason and it's been brought up a couple times about introducing like a JavaScript unit test framework and a rails we give you a default Ruby test framework why wouldn't we give you a default JavaScript test framework and this because of this perspective that's why we don't really do it and what's funny about this too is that if you look at base camp so like if you read the blog posts about base camp on signal versus noise they talk about like a smattering of JavaScript in base camp so base camp uses backbone as a JavaScript framework but you don't need JavaScript frameworks for your app because you'd write you know cash digest you only need a little bit of JavaScript but their ends up being almost a megabyte of JavaScript in base camp next a travesty I on the other hand which is a single page application and use this ember that super heavyweight framework that no one would ever want to use because it's so much JavaScript only has 660 kilobytes of JavaScript right so so there's a question and a difference in like rhetoric here between like you don't need to write a ton of JavaScript you just write a Meg of it by hand or you could use a full stack framework like we do on the server side and you write a little bit of JavaScript in the framework does a lot of lifting for you and you end up with like the same sort of result right so so I think this is really problematic because ultimately rails is really good at being a back-end for JavaScript heavy frameworks like regardless of not having any features specific to it I think that rails is a fantastic choice for that use case and it's still the best one that currently exists but I think that we could make it even better and it sort of it sort of bothers me that we don't like some people do but some people don't want to actually make it better for that use case I'm actually not that big of a fan of JavaScript heavy applications personally but I am a fan of helping people solve their problems and a lot of people have that problem and so I want to help them solve it even if I don't necessarily have their problems myself and this is sort of relating to that question about blocking with turbo links for example so two of the gems that really really helped make rails even better that improve javascript stuff is active model serializers is one of them right so actor model serializers was merged into rails and then was reverted from rails and it was said make it into a gemman if it's popular enough will include it so in that time it had sixteen thousand seventeen thousand downloads and there's been like two thousand downloads for that current version rails API another awesome feature that was super excited psyched to get into rails for this gives you like an API controller that doesn't use the full stack of middleware and you know like slims down things that you don't need if you're just doing a JSON back end to a web app reverted make it a plug-in if it gets enough downloads you'll be able to you will merge it back in so seventeen thousand downloads for this one and fifteen thousand for this this current version 14 thousand for this version remember that routing concerns feature it was made into a gem before it got merged into rails uh but it had 477 downloads which was definitely made it popular enough to be like in rails core by default right and so like this is the problem that I see with like moving forward is that because certain use cases are favored over other use cases I fear that rails is only going to be good for building basecamp apps which you know base camp is sort of like not even the app it purports to be but like the apps that base cant pretend like it is is the one that rails is like focusing on that use case as opposed to the javascript heavy applications that everyone is talking about going forward right like how many JavaScript application how many JavaScript presentations do you see it every Ruby and Python conference right like this conference is called roop i but it has a ton of javascript stuff right we all write JavaScript and so I really want to see rails get better at that case regardless of like whether it is in core not so I really encourage you to still use rails for back end stuff like I don't want to tell you that as bad either and you should use both of those gems rails API and active model serializers are both really really fantastic and if you use ember there's been a lot of work on making ember go to one point oh but you has an interest in making acta model serializers and ember data talk to each other so if you use acta model see you lasers and rails API and ember it will all play together super well and myself and a couple other people are putting a lot of effort into making that particular use case a really really nice one so if you plan on building ember applications rails is a good choice today and will continue to be a good choice in the future but I would like to see it continue to be a good choice and hopefully someday we'll be able to convince people to put that stuff in the core instead of having it be this like second-class install some gems citizen kind of situation so so ultimately i'm still really excited so I sort of ended on this downer I left the stock photo thing in the middle of this guy's photo because I thought it made it even better but uh like ultimately I'm really excited for reals for to get out and i wouldn't spend a lot of my time working on it if I didn't think it was going to be a good release so maybe I should have ended on the positive note instead of a negative one but if you look at the number of features that I talked about the ones that I think that are bad and the ones that they think that are good it's very heavily favored in the good so I'm excited to use rails for stuff and use that stuff and so I hope that you are too so that is why you should care about it and why I care about it so thanks for for listening I really dislike questions overall because I feel that like blocks everyone else in the room so if you have question a question or two I think I like two or three minutes so if it'll take like one or two questions that you feel is relevant to everyone in the room and is not like injecting your own opinion over like everyone else's time I'll be more than happy to take a question but if not you can email me at anytime about anything so if if I don't get to your question right now you can talk to me and or email me about anything I already got one from you really there's non-doctor Nick what's the gym I did it what's an example of a question is valid for everyone and what's a question so here's the thing people I've gone to so many conference talks where people not my talks but other talks for people are like well why doesn't it do this crazy thing that I really want in like it ends up being this like soap box for people so like that's why I last time I said this is the conference everybody clapped like yay we hate questions so I don't know whatever it's a preference but what's up so three years ago when race 3 was released yes said that he's concerned about the growing size of the rock star yes he said that he wants to do something about you know if it was smaller so the question is erin's keynote at railsconf 2011 or 2010 Africa which one was about the fact that rails performance had an issue because of the middleware stack so like going into and out of that huge deep stack cause performance problems Aaron is working on something that is that will fix that issue it's not significantly better or worse in rails for we haven't added a lot and we haven't removed a lot like maybe it's different by one or two but it's not significantly different there is some work being done to improve that case but it is not really public yet and so it's the same kind of deal it's like when it's done it's done what yeah Joseph are 18 because it was applied related to the garbage collection ok so Joseph said that it's like mostly like a 18 was very severe and since rails for supporting 19 it's not as big of a deal basically like an appropriate yeah so so there's work being done in that area but yeah it's not like public and it's not going into rails for at least so you may see something about that in the future alright zero minutes so thanks everybody