5 ms·

Ruby on Rails Tutorial Chapter 12 is out

67 points by mhartl 16y ago

mhartl 16y ago
Here's a direct link to the new chapter: http://www.railstutorial.org/chapters/following-users#top http://www.railstutorial.org/chapters/following-users#top
- jpcx01 16y ago
  Great work! This tutorial is a huge asset to the Rails community.
  - mhartl 16y ago
    Thanks! Glad you like it. :-)
barrydahlberg 16y ago
I'm working through this now. As an experienced ASP.Net developer it's a great intro to how things are done in the Rails world.
timesarrow 16y ago
I think this tutorial is THE place to start to learn rails.
rjett 16y ago
Are you still planning to release screencasts as part of railstutorial?
- mhartl 16y ago
  Indeed I am! Sign up for an email notification at http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts :-)
deleted 16y ago
[deleted]
ptimothyp 16y ago
This is an awesome tutorial one of the best I have seen in quite a while. This book is highly addictive.
samd 16y ago
This is an awesome tutorial not just for programmers new to Rails, but also people new to programming and web development. I'm glad you gave an overview of editors, IDEs, version control, and all the other tools associated with development that you usually don't see mentioned in programming books.
- pstinnett 16y ago
  I couldn't agree more. This is _the_ place to go for learning Rails _and_ about other programming must-haves.
MartinMond 16y ago
Any plans on releasing PolyTeXnic soon(ish)?
- mhartl 16y ago
  (N.B. For those who don't know, PolyTeXnic is the markup system (built on top of LaTeX) used to produce the Ruby on Rails Tutorial book.) There's a lot of prepwork to be done before PolyTeXnic is ready for release—among other things, I want to write some good documentation first, which IMHO is important for an open-source project but takes a lot of time—so it won't be available soon(ish). More like eventually(ish). :-)
stevenwei 16y ago
This tutorial is great. One question for experienced Rails folks: I noticed that a lot of the test code seems to be somewhat redundant and not actually testing many different paths of execution. E.g. I saw a lot of test cases like this in his examples: it "should be successful" do get :new response.should be_success end it "should have a follower attribute" do @relationship.should respond_to(:follower) end it "should have a followers method" do @user.should respond_to(:followers) end it "should render the home page" do post :create, :micropost => @attr response.should render_template('pages/home') end Writing a unit test that verifies that some object has a new method/attribute that you're about to add to it, or that some request returns a 200 OK, or that some request renders a specific template? It all seems very...boilerplate to me. Is this a common practice?
- mhartl 16y ago
  This is a good question, and I actually just added a footnote yesterday to address it. The deal is that, when doing test-driven development, you often bounce back and forth between test and application code, like this: it "should be successful" do get :new response.should be_success end Then def new end Next you'd add a test for what the 'new' action actually does, and then get the 'new' action to do it. In a book, interleaving the test and application code like this is rather cumbersome. The real payoff to this approach will be in the upcoming screencast series (http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts), which will allow me to interleave the tests and application code much more finely. Together with Autotest continuous testing and Growl notifications, the screencasts will show just how addictive TDD can be. I should probably motivate this practice better in the book, because it is counter-intuitive. In fact, I thought this technique was crazy when I first saw it. (The same goes for TDD in general.) But it's amazing how much easier it is to get started on a method when the first step is "make sure the method is there". Indeed, such tests aren't really designed to make the application better-tested; they're designed to help the programmer stay in the zone. That being said, there probably are some places where such fine-grained tests aren't worth the trouble, or might even be confusing. I'm about to embark on a Rails 3 update of the book, so I'll keep my eye out for tests that should be removed. If you have any suggestions for tests that should be on the chopping block, please let me know (http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback).
fdschoeneman 16y ago
I've been through the tutorial using Rails 2.x and also 3beta. The tests don't all work in 3beta but in case you're wondering, yes, you can almost the entire app in 3.0. It is indeed a wonderful thing and Michael has, I think, become one of the largest gems in the Rails community with this contribution. -- Fred
ApolloRising 16y ago
What's the best way to send you feedback from a non hardcore programmer perspective on a chapter by chapter basis? I am very much enjoying your book and wanted to contribute back.
- mhartl 16y ago
  There's a feedback link in the top menu of the website and also on the right sidebar. In the PDF, each page has a feedback link in the footer. Or just click here: http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback
elbenshira 16y ago
I've gone through 9 chapters of this tutorial, but I don't know if I want to finish it. The first few chapters were great and a lot of fun. Michael removed a lot of magic that I never understood. But I suppose my worries are irreconcilable: Michael attempts to please both programmers and non-programmers at the same time. For example, I enjoyed things such as Figure 2.11 (a detailed explanation of MVC in Rails), but then Michael flashes through Ruby in Chapter 4. I understood it because I'm a programmer, but I don't know if any of the other target audiences would. And as the tutorial progressed, I felt that Michael explained concepts and topics less and less. For example, for user sign-in/out, another Rails book simply insert a session[:user_id] = @user.id, but Michael goes through the trouble of creating a new User.remeber_token field (Chapter 9). Why? Security? Surely not, since he previously explained that cookies are checksumed to make sure that it was not tampered with on the client side. Efficiency? Nope. The session[:user_id] = @user.id is more efficient. Then there are also other quirks such as modifying the Users table everytime the user logs in (it calls User.remember_me!). (I might be wrong about this, please check me). I started this tutorial to remove some magic fairy dust from my eyes, but I'm afraid it has blinded me even more. Michael, I'd really appreciate it if you could answer some of my questions. NOTE: I've played around w/ RoR before, but not much.
- mhartl 16y ago
  I think that as the tutorial progresses, the number of potential confusions increases combinatorially. I've done my best to answer them in the text, but given the broad audience for the book it's hard to anticipate all possible questions. I'll do my best to answer your questions. The session[:user_id] solution you mention only persists over one session, i.e., if a user closes his browser, his session is lost. The tutorial's remember token, on the other hand, persists even after the browser is closed. Once you have a persistent cookie, though, you have a potential security breach. The reason a persistent cookie can't just be the user id is because it can be trivially spoofed: if you can simulate a cookie with id 17 (not hard with, e.g., Perl, Python, or Ruby), you can log in as user 17. That would be a Bad Thing™. By hashing the user id with a salt, we avoid this problem. I've made a note to motivate the remember token better in the tutorial. Saving the user on each login is correct; it's needed to change the remember token for security purposes. That the remember token doesn't currently change on each login is a bug in the tutorial, and I'll fix it ASAP (probably tomorrow). (The id-salt hash should also include a timestamp.) Finally, Rails does have a lot of magic, which is a source of its power but is also a potential stumbling block. The Rails Tutorial book is designed not to remove fairy dust but rather to teach you how to use it—mainly because most Rails application developers never need to know what's behind the curtain. (Indeed, in many cases I don't know, nor do I particularly care. After all, Ruby is mostly written in C, but you don't have to dig into the C source to use Ruby.) If you're a pull-back-the-curtain kind of guy, I recommend The Rails Way as a companion volume to Rails Tutorial. You've raised some good issues here. Let me know if you have any other suggestions: http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback

67 points by mhartl 16y ago

Here's a direct link to the new chapter: http://www.railstutorial.org/chapters/following-users#top http://www.railstutorial.org/chapters/following-users#top

jpcx01 16y ago
Great work! This tutorial is a huge asset to the Rails community.
- mhartl 16y ago
  Thanks! Glad you like it. :-)

barrydahlberg 16y ago

I'm working through this now. As an experienced ASP.Net developer it's a great intro to how things are done in the Rails world.

timesarrow 16y ago

I think this tutorial is THE place to start to learn rails.

rjett 16y ago

Are you still planning to release screencasts as part of railstutorial?

mhartl 16y ago
Indeed I am! Sign up for an email notification at http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts :-)

deleted 16y ago

[deleted]

ptimothyp 16y ago

This is an awesome tutorial one of the best I have seen in quite a while. This book is highly addictive.

samd 16y ago

This is an awesome tutorial not just for programmers new to Rails, but also people new to programming and web development. I'm glad you gave an overview of editors, IDEs, version control, and all the other tools associated with development that you usually don't see mentioned in programming books.

pstinnett 16y ago
I couldn't agree more. This is _the_ place to go for learning Rails _and_ about other programming must-haves.

MartinMond 16y ago

Any plans on releasing PolyTeXnic soon(ish)?

mhartl 16y ago
(N.B. For those who don't know, PolyTeXnic is the markup system (built on top of LaTeX) used to produce the Ruby on Rails Tutorial book.) There's a lot of prepwork to be done before PolyTeXnic is ready for release—among other things, I want to write some good documentation first, which IMHO is important for an open-source project but takes a lot of time—so it won't be available soon(ish). More like eventually(ish). :-)

stevenwei 16y ago

This tutorial is great. One question for experienced Rails folks: I noticed that a lot of the test code seems to be somewhat redundant and not actually testing many different paths of execution. E.g. I saw a lot of test cases like this in his examples: it "should be successful" do get :new response.should be_success end it "should have a follower attribute" do @relationship.should respond_to(:follower) end it "should have a followers method" do @user.should respond_to(:followers) end it "should render the home page" do post :create, :micropost => @attr response.should render_template('pages/home') end Writing a unit test that verifies that some object has a new method/attribute that you're about to add to it, or that some request returns a 200 OK, or that some request renders a specific template? It all seems very...boilerplate to me. Is this a common practice?

mhartl 16y ago
This is a good question, and I actually just added a footnote yesterday to address it. The deal is that, when doing test-driven development, you often bounce back and forth between test and application code, like this: it "should be successful" do get :new response.should be_success end Then def new end Next you'd add a test for what the 'new' action actually does, and then get the 'new' action to do it. In a book, interleaving the test and application code like this is rather cumbersome. The real payoff to this approach will be in the upcoming screencast series (http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts), which will allow me to interleave the tests and application code much more finely. Together with Autotest continuous testing and Growl notifications, the screencasts will show just how addictive TDD can be. I should probably motivate this practice better in the book, because it is counter-intuitive. In fact, I thought this technique was crazy when I first saw it. (The same goes for TDD in general.) But it's amazing how much easier it is to get started on a method when the first step is "make sure the method is there". Indeed, such tests aren't really designed to make the application better-tested; they're designed to help the programmer stay in the zone. That being said, there probably are some places where such fine-grained tests aren't worth the trouble, or might even be confusing. I'm about to embark on a Rails 3 update of the book, so I'll keep my eye out for tests that should be removed. If you have any suggestions for tests that should be on the chopping block, please let me know (http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback).

fdschoeneman 16y ago

I've been through the tutorial using Rails 2.x and also 3beta. The tests don't all work in 3beta but in case you're wondering, yes, you can almost the entire app in 3.0. It is indeed a wonderful thing and Michael has, I think, become one of the largest gems in the Rails community with this contribution. -- Fred

ApolloRising 16y ago

What's the best way to send you feedback from a non hardcore programmer perspective on a chapter by chapter basis? I am very much enjoying your book and wanted to contribute back.

mhartl 16y ago
There's a feedback link in the top menu of the website and also on the right sidebar. In the PDF, each page has a feedback link in the footer. Or just click here: http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback

elbenshira 16y ago

I've gone through 9 chapters of this tutorial, but I don't know if I want to finish it. The first few chapters were great and a lot of fun. Michael removed a lot of magic that I never understood. But I suppose my worries are irreconcilable: Michael attempts to please both programmers and non-programmers at the same time. For example, I enjoyed things such as Figure 2.11 (a detailed explanation of MVC in Rails), but then Michael flashes through Ruby in Chapter 4. I understood it because I'm a programmer, but I don't know if any of the other target audiences would. And as the tutorial progressed, I felt that Michael explained concepts and topics less and less. For example, for user sign-in/out, another Rails book simply insert a session[:user_id] = @user.id, but Michael goes through the trouble of creating a new User.remeber_token field (Chapter 9). Why? Security? Surely not, since he previously explained that cookies are checksumed to make sure that it was not tampered with on the client side. Efficiency? Nope. The session[:user_id] = @user.id is more efficient. Then there are also other quirks such as modifying the Users table everytime the user logs in (it calls User.remember_me!). (I might be wrong about this, please check me). I started this tutorial to remove some magic fairy dust from my eyes, but I'm afraid it has blinded me even more. Michael, I'd really appreciate it if you could answer some of my questions. NOTE: I've played around w/ RoR before, but not much.

mhartl 16y ago
I think that as the tutorial progresses, the number of potential confusions increases combinatorially. I've done my best to answer them in the text, but given the broad audience for the book it's hard to anticipate all possible questions. I'll do my best to answer your questions. The session[:user_id] solution you mention only persists over one session, i.e., if a user closes his browser, his session is lost. The tutorial's remember token, on the other hand, persists even after the browser is closed. Once you have a persistent cookie, though, you have a potential security breach. The reason a persistent cookie can't just be the user id is because it can be trivially spoofed: if you can simulate a cookie with id 17 (not hard with, e.g., Perl, Python, or Ruby), you can log in as user 17. That would be a Bad Thing™. By hashing the user id with a salt, we avoid this problem. I've made a note to motivate the remember token better in the tutorial. Saving the user on each login is correct; it's needed to change the remember token for security purposes. That the remember token doesn't currently change on each login is a bug in the tutorial, and I'll fix it ASAP (probably tomorrow). (The id-salt hash should also include a timestamp.) Finally, Rails does have a lot of magic, which is a source of its power but is also a potential stumbling block. The Rails Tutorial book is designed not to remove fairy dust but rather to teach you how to use it—mainly because most Rails application developers never need to know what's behind the curtain. (Indeed, in many cases I don't know, nor do I particularly care. After all, Ruby is mostly written in C, but you don't have to dig into the C source to use Ruby.) If you're a pull-back-the-curtain kind of guy, I recommend The Rails Way as a companion volume to Rails Tutorial. You've raised some good issues here. Let me know if you have any other suggestions: http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback