<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">You should do a training course Murray, I bet you'd be well good at it.<div><br></div><div>:P</div><div><br></div><div>- James</div><div><br><div><div>On 16 Mar 2012, at 10:47, Murray Steele wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">If someone is new to rails, but not programming, I think there's probably 1 thing they must learn first: "if it seems difficult then it's not the rails way and you should stop trying".<div><br></div><div>
Then you need to teach them what the rails way is. I suspect that doing this without rails might even be useful. Looking back at all the rails releases since you started on it, there's a core thing in each one.</div>
<div><br></div><div>1.0 (or earlier) was MVC</div><div>1.2 was the REST stuff</div><div>2.x ?? (I can't remember, but I assume there was some base innovation here other than feature creep - maybe it wasn't in core web stuff)</div>
<div>3.0 was cross site scripting safety (also rack & bundler, and lots of wanking about in the rails codebase itself but these seem very rubyish, or railsish, and not general ideas about web development)</div><div>3.1 was asset pipeline<br>
<div><br></div><div>I'd be inclined to teach someone about MVC then how you do that in rails. Then make them grok REST and follow that up by showing how you layer that on top of the bare bones MVC in rails that you taught them earlier. Then move onto the next thing. It's a 2 pronged attack, teach them good web development practices first, and how to do it with rails 2nd. </div>
<div><br></div><div>I think a lot of rails is super obvious and easy if you know how things used to be done (admittedly, because that's how I learned it). Often the changes in rails between releases have been about optimising programmer time. Usually in the form of "We noticed that everyone always types out blah blah blah to achieve X, how about we type blah instead and assume that you wanted blah blah blah as the default. You can still type blah blah bloo if you something custom.". Take routes as an example:</div>
<div><br></div><div>Explaining routes with "just put resources :flying_badgers in routes.rb and you get urls" is pretty magical and leaves people twisting in the wind when they have to stray from the standard id-based resource form.</div>
<div><br></div><div>If instead you say "first put get '/flying_badgers' => 'flying_badgers#index' and this gets you a route that shows you all the flying badgers, and this is run by the index action on the flying badgers controller" and then "now add get '/flying_badgers/:id' => 'flying_badgers#show' to see an individual flying badger" and so on down to "delete '/flying_badgers/:id => 'flying_badgers#destroy'". Taking diversions along the way to explain the plumbing and route helpers for views etc... they'll understand what routes.rb is and how it connects up to your controllers. You can then say, "Oh, by the way, all those things are what we call the standard REST actions and REST is about resources and it's what we do all the time, so you can replace it with resources :flying_badgers" and I think people will understand it better. You can also then explain about shortcuts for routes (redirect_to @flying_badger instead of redirect_to flying_badger_path(@flying_badger), because it's all about resources.</div>
<div><br></div><div>Rails took years to get to where it is, but I'm pretty sure we could bring someone from nothing to understanding rails 3.2 in way less time and still give them the understanding that we have about why we do things the way we do.</div>
<div><br></div><div>I don't know if any existing tutorials explain things like this, nor do I know if it would work, but it feels right to me.</div><div><br></div><div>Also, as James suggests below, they should sit next to me (this may not scale) ;)</div>
<div><br><div class="gmail_quote">On 16 March 2012 09:40, James Higgs <span dir="ltr"><<a href="mailto:jameshiggs@gmail.com">jameshiggs@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(I tried to post this last night but failed. I sent it to Tom off-list, but I thought it worth posting here anyway in case others might find it useful or have further suggestions)<br>
<br>
I was in exactly this situation about 8 months ago. I had done a small amount of Rails on 2.x but not enough for anything terribly advanced to lodge in my memory. My background is not CS, but I have used multiple languages and frameworks over the roughly 20 years, latterly with a bias towards .NET and C#. (Although I have since repented, I do still miss certain things about C#, but that's another story.)<br>
<br>
I started with the Rails Tutorial - <a href="http://ruby.railstutorial.org/" target="_blank">http://ruby.railstutorial.org/</a> - stepping through it laboriously even though some of it was stuff I already knew or was obvious. At every stage I verified that the tests ran and that the output in the browser was as expected. Finding and fixing problems taught me a lot.<br>
<br>
Having completed that, I had a personal project that I wanted to do and so I battled my way through that using the stuff I had learned from the tutorial and brute force web searches/trying stuff. I also had a copy of the most recent edition of The Rails Way on my desk. That's a great book, but it would have made no sense to me if I hadn't done the other stuff first.<br>
<br>
One of the things that tripped me up was the switch to CoffeeScript and the asset pipeline which weren't covered in any of the resources at the time (this might have changed since).<br>
<br>
I then started on a big Rails project (still going at the time of writing).<br>
<br>
We're not using RSpec or Cucumber, but rather MiniTest with FactoryGirl and Capybara, so there were differences there that I needed to master. I was (and am) very lucky to be sitting next to Murray the whole time, and he's been very patient with my stupid questions. Just looking at and trying to understand a top notch Rubyist's code was an invaluable help, but nothing beats asking stupid questions and getting patient replies.<br>
<br>
The things I had most difficulty with were routes (when we strayed from the basics) and associations (the same). I also had difficulty writing sensible and useful functional tests.<br>
<br>
Initially, FactoryGirl and Capybara were indistinguishable from magic. One of the biggest issues for me was distinguishing at what level the ninja shit was occurring: in Ruby itself, in Rails, in a gem or in magic in our lib folder, or some combination.<br>
<br>
I'd say that a thorough grounding in routes, associations and validations are a must, as is understanding how tests work and what a good, repeatable test looks like.<br>
<br>
I can't speak for the results, but I feel like I understand heaps more than I did at the start and I seem to be asking fewer stupid questions. There are undoubtedly other resources that could have assisted me, but the ones I mention here worked well.<br>
<br>
For what it's worth, I didn't try to grasp plain Ruby first. Perhaps that would have made things easier though. I still feel like there's loads of stuff in the libraries that I don't fully get, especially in collections (Paul Battley's talk at Ruby Manor helped a good deal there).<br>
<br>
Getting someone to explain rvm/gemsets/gems/bundler/homebrew and all that plumbing also really helped. I feel like it's still far too difficult to get the stack up and running on a modern Mac (Xcode nonsense doesn't help at all there).<br>
<br>
Aside from that, subscribing to a bunch of Ruby/Rails blogs, following Rubyists on Twitter, lurking on this list, watching Ruby Manor videos and generally trying to immerse myself in this world also helped immeasurably.<br>
<br>
Hope that's useful.<br>
<br>
Cheers,<br>
James<br>
<div class="HOEnZb"><div class="h5"><br>
On 15 Mar 2012, at 18:01, Tom Armitage wrote:<br>
<br>
> So: I've been using Rails since god, pre 1.0, I think. Not very well,<br>
> mind, but a while, nontheless.<br>
><br>
> I'm thinking at the moment about where to begin explaining it to new<br>
> users (in particular: programmers who are very technically competent,<br>
> perhaps with a CS background, but no direct experience of Ruby or<br>
> Rails).<br>
><br>
> And, looking at Rails 3.2 in 2012... I realise I have no idea where to<br>
> begin. A lot of what I've learned is stored as diffs on top of "the<br>
> old way of doing things"; it makes sense because I started learning it<br>
> years ago.<br>
><br>
> But where would you send a competent programmer in 2012 looking to<br>
> start from scratch with Rails? My usual recommendation has always been<br>
> getting a good grasp on Ruby, perhaps through The Ruby Way or the (at<br>
> the time) excellent Ruby For Rails, which helped me understand the<br>
> language loads, though I fear it now may have dated/be irrelevant.<br>
><br>
> Where, say, would you point as a starting point for testing/BDD in<br>
> Ruby, given "four years of the mailing list and user group" isn't<br>
> enough?<br>
><br>
> I'm curious, because every now and then I look at Rails as an outsider<br>
> and roll my eyes a bit...<br>
><br>
> t.<br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
> <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br>
_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
</div></div></blockquote></div><br></div></div>
_______________________________________________<br>Chat mailing list<br><a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></blockquote></div><br></div></body></html>