Comment by grey-area | Hacker News Reader

Comment by grey-area | Hacker News Reader

Parent Full thread

The guides on the ror website are pretty good:

http://guides.rubyonrails.org/

Which bits did you find were magic? The bits of convention I can think of you'd have to know about are:

DB naming conventions - these are used so that it can do joins etc easily behind the scenes, they're pretty simple so not a huge problem I find.

Rendering at the end of controller actions - it'll render the template with the same path as your route - again relatively straightforward.

Class loading - lots of things are loaded at startup time, so that you don't have to include files - I have mixed feelings about this, it feels easy and simple at first, but could leave you unsure where code comes from or which methods you can use in which files (e.g. view helpers). Definitely more magic.

One other area which does lead to real problems is that rails sites often use a lot of libraries in the form of gems - this leads to unknown, sometimes poorly maintained or inappropriate code being pulled in at runtime, and makes it far harder to reason about things like say authentication if using a gem. This is my biggest complaint with rails - lack of transparency of code paths when using gems like devise, paperclip etc but it is unfortunately quite common in web frameworks

They actually got rid of quite a few bits of method_missing madness I think recently so that magic is gone at least (all those magic find_by_ methods are deprecated or removed, not sure which as I never used them). I haven't found the conventions get in the way much as it's something you learn once and can apply anywhere, but completely understand why someone might object to some of the magic setup for helpers/rendering.

The routing system and associated view helpers can really get confusing.

For example:

    link_to @story.title, @story

You have to know that rails has some automatic routing based on the class of an object. If @story is a Story class, rails basically does this underneath:

    link_to @story.title, send("#{@story.class.name.downcase}_path".to_sym, @story.to_param)

There's implicit conversion of class names going on under the hood in a few places. It's all documented but it's not easy to find the documentation when you don't know what you are looking for.

The thing that really screws up people starting with rails is not understanding the various layers (html, views, controllers, models, http, etc.) and how rails puts those together. If you don't know how to do web programming with basic html and php, rails will eat you alive with it's seemingly magical behaviors.

I have to agree - The path helpers are very opaque. It would probably do Rails well to generate a app/helpers/path_helper.rb file with the actual implementations in them.

`rake routes` will output the routes and paths. Appending _path or _url to the path will generate appropriate methods.

Sure. But that still doesn't tell me exactly which arguments they take. Or give me an opportunity to debug the code when it doesn't do as I expect. I realise that it just-works (tm). It's when it doesn't, it gets problematic.

It's actually pretty easy to tell the parameters they take if you look at the url for the route.

For:

    story GET   /story/:id(.:format)  story#show

You get

    story_path(id)
    story_path(id, format)
    story_url(id)
    story_url(id, format)

In practice it doesn't cause as many problems as you think, even in large applications.

When learning Rails, I found the DB naming conventions confusing enough that I wrote a blog post summarizing how everything is supposed to be named when I figured it out, since nobody else seems to have:

https://shinynuggetsofcode.wordpress.com/2013/09/30/conventi...

Like a lot of the Rails stuff, it feels like amazing cool magic when things just work. But then when they don't work and do something weird instead of what you expected, it feels like it takes forever to figure out why, what was named wrong, and what it's supposed to be named.

Reply on news.ycombinator.com