6 ms·
Chapter 6 of the Rails Tutorial, 2nd Edition is out ("Modeling users")
- fonzie 15y agoMichael, this is fantastic once again. Thanks a bunch. Really looking forward to those screencasts whenever they come out also.
- mhartl 15y agoYou're welcome! And I didn't realize The Fonz was a fan. :-)
- james-fend 15y agoGreat stuff Michael!
- pg_bot 15y agoMichael, your rails tutorial continues to be the best source for those who want to learn the basics of rails. I used it as an introduction, and I recommend it to anyone who wants to begin creating web apps. I am glad to see that it was enough of a success to warrant a second edition, and wish you continued success.
- mhartl 15y agoSee also the original announcement of the 2nd Edition, which includes a FAQ and a list of new features: http://news.railstutorial.org/ruby-on-rails-tutorial-second-edition-updated http://news.railstutorial.org/ruby-on-rails-tutorial-second-... The biggest changes are: * A full update to Rails 3.2, including coverage of the asset pipeline * A complete rewrite of the authentication & authorization system, taking advantage of the new has_secure_password method * A revised test suite using the latest techniques in RSpec programming
- tptacek 15y agoI know i'm harping here, Michael, but: Another step that isn’t strictly necessary at this stage—but is a really good idea nevertheless—is to tell Rails which attributes of the model are accessible, i.e., which attributes can be modified by outside users (such as users submitting requests with web browsers). That's not what attr_accessible means --- the real meaning of attr_accessible is subtly different in a way that leads people to make mistakes. attr_accessible means attributes can be modified automatically based on user input. End-user web browser requests can modify things that aren't in attr_accessible --- you just have to write the code to let them. The error this leads to is overly-permissive attr_accessible statements, because people fall into a trap of believing anything that might be changed as a direct result of a user request must be in the attr_accessible statement.
- mhartl 15y agoIf this is 'harping', please keep doing it. Mass assignment/attr_accessible is an important and oft-neglected issue, and I appreciate your taking the time to help. I agree that readers could get the wrong idea by thinking they're better-protected than they really are. I've clarified the wording by adding "automatically" as a modifier: i.e., which attributes can be modified automatically by outside users The detailed meaning is then deferred to later in the tutorial, when the effects of attr_accessible are illustrated with concrete examples of mass assignment.
- snprbob86 15y ago`attr_accessible` and friends are a nightmare anyway. They push a controller-layer concern into the model-layer. It breaks the hash-initialization syntax that is so useful in irb, in unit tests, in background jobs, etc. Instead, I've been using ActiveSupport's Hash#slice method in my controllers.
- tptacek 15y agoDeclarative syntax for which attributes the model designer is comfortable exposing to mass assignment seems like a perfectly legitimate model concern. In what sense is attr_accessible different from, say, "validate"?
- snprbob86 15y agoIt mascarades and is documented as a security feature, but it's a superficial restriction. You could simply loop and send("#{key}=", value) instead of calling attributes=(hash). In practice, all it does it prevent you from writing `MyModel.new(:foo => bar)` and force you to write `m = MyModel.new; m.foo = bar` This is simply annoying at the repl. Validation applies always the same (or when some predicates are satisfied), but restriction on changing fields can vary by view or via permissions (ie. only admins can flip that bit!) The security concern comes up when you bring "params" into the picture. You don't want to ever do: MyModel.new(params) for fear of params[:is_admin] == true. A better solution would be to automatically mark the values in `params` as tainted and throw an error on mass-assignment of tainted values. This way you can still use mass assignment for non-user-input (like in tests or at the repl). You could have an `safe_attrs` to disable tainted value filtering for some known-safe attributes.
- bomatson 15y agoThank you so much Michael, Rails Tutorial has helped me go from zero Rails knowledge to deploying apps. Please keep it up!
- wasd 15y agoMichael, this is great and incredible stuff. I think your work goes unmatched and that there is no introduction (paid or free) that is as comprehensive or welcoming. I have passed on (even forced) this onto all my friends. Even those who know Rails so that if someone may ask them in the future, they will point them in your direction. Putting that behind us, I hope you're not planning to post on HN every week or two when a new chapter is released. I think your last post and perhaps one when the book is completed would be sufficient.
- mhartl 15y agoThanks for the feedback and suggestion. I can understand not wanting to have an announcement hit the HN front page every time a new chapter is released. But even if I don't submit the story, the chances are good that someone else will. By submitting it myself, I can control the timing; in particular, I can make sure to be available to respond to comments. In any case, if people don't vote it up, the story will soon disappear.
- re_todd 15y agoThanks Michael, I was having a hard time understanding TDD and git until I went through your tutorial. Also, although I had been programming in Rails for a couple years, it really helped me understand some of the basics of Rails that I had somehow missed.
- geoffroy 15y agomany thanks michael, your tutorial is really the best to get started with web development, from bdd to hosting. Hats off!
- xoen 15y agoThank you very much, I hope to be slow enought to wait the following chapters :P