[LRUG] Beginning Rails in 2012

Fri Mar 16 07:54:27 PDT 2012

> if it seems difficult then it's not the rails way and you should stop trying".
I would differ. Rails makes a hash of doing REST, and most of the
object design in Rails is very very ugly. Worse still, this ugliness
is often forced onto the users of the framework, and then passed of as
the 'Rails Way' to new programmers who basically learn bad habits as a
consequence.

Rails makes building web apps easy, but makes good OO difficult. This
has been getting better since 3.0 and up (thanks in large part to
Merb) but is still far from setting good examples.

Best,
Sidu.
http://twitter.com/ponnappa

On 16 March 2012 16:17, Murray Steele <murray.steele at gmail.com> wrote:
> 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".
>
> 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.
>
> 1.0 (or earlier) was MVC
> 1.2 was the REST stuff
> 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)
> 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)
> 3.1 was asset pipeline
>
> 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.
>
> 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:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Also, as James suggests below, they should sit next to me (this may not
> scale) ;)
>
> On 16 March 2012 09:40, James Higgs <jameshiggs at gmail.com> wrote:
>>
>> (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)
>>
>> 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.)
>>
>> I started with the Rails Tutorial - http://ruby.railstutorial.org/ -
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> I then started on a big Rails project (still going at the time of
>> writing).
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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).
>>
>> 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).
>>
>> 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.
>>
>> Hope that's useful.
>>
>> Cheers,
>> James
>>
>> On 15 Mar 2012, at 18:01, Tom Armitage wrote:
>>
>> > So: I've been using Rails since god, pre 1.0, I think. Not very well,
>> > mind, but a while, nontheless.
>> >
>> > I'm thinking at the moment about where to begin explaining it to new
>> > users (in particular: programmers who are very technically competent,
>> > perhaps with a CS background, but no direct experience of Ruby or
>> > Rails).
>> >
>> > And, looking at Rails 3.2 in 2012... I realise I have no idea where to
>> > begin. A lot of what I've learned is stored as diffs on top of "the
>> > old way of doing things"; it makes sense because I started learning it
>> > years ago.
>> >
>> > But where would you send a competent programmer in 2012 looking to
>> > start from scratch with Rails? My usual recommendation has always been
>> > getting a good grasp on Ruby, perhaps through The Ruby Way or the (at
>> > the time) excellent Ruby For Rails, which helped me understand the
>> > language loads, though I fear it now may have dated/be irrelevant.
>> >
>> > Where, say, would you point as a starting point for testing/BDD in
>> > Ruby, given "four years of the mailing list and user group" isn't
>> > enough?
>> >
>> > I'm curious, because every now and then I look at Rails as an outsider
>> > and roll my eyes a bit...
>> >
>> > t.
>> > _______________________________________________
>> > Chat mailing list
>> > Chat at lists.lrug.org
>> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>