Rails conventions

[Brian Postow]

Hello!

I'm an experienced programmer, who's starting to use Ruby on Rails for the first time. I need some documentation that JUST explains how variable names are manipulated. Things I need to understand:

• When Rails will automatically convert between CamelCase and snake_case  (like How does migrate know to break up Add_Foo_Bar_Baz_To_Buq as adding a FooBarBaz column to the Buq table, and what will it to with Add_Foo_To_Baz_To_Buq or Add_FooBarBaz_To_Buq?)
• When Rails will automatically convert between singular and plural
• What the correct (conventional) form is for variables/class names/DB tables columns/method names of various types
• Given a name of a given form, what kind of thing does RoR think it is and where is RoR looking for it?
• Stuff like that...
  

I don't need a book that explains how to write a program from scratch (I have a large one that I'm already working with). I don't need something that explains how Ruby works, I can learn the language on my own. I need a reference where I can look things up easily.

Also, if there is a better resource to ask this question, that would be great as well. There doesn't appear to be a Stack Exchange site for asking resource recommendation questions...

Thanks!

[Hassan Schroeder]

On Tue, Mar 27, 2018 at 6:52 AM, Brian Postow <bpo...@gmail.com> wrote:

> I'm an experienced programmer, who's starting to use Ruby on Rails for the
> first time. I need some documentation that JUST explains how variable names
> are manipulated. Things I need to understand:

The questions you're asking make me think you're conflating "Rails"
and "Ruby". You might want to start at https://www.ruby-lang.org/
with the "Ruby in 20 Minutes" and "Ruby From Other Languages"
sections first.

Aside from that, have you looked at the Rails guides? They might
clarify some of your Rails-specific questions.

http://guides.rubyonrails.org/

HTH!
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
twitter: @hassan
Consulting Availability : Silicon Valley or remote

[Brian Postow]

No, I'm pretty sure that everything I'm looking at is strictly rails. A friend pointed me at: https://gist.github.com/iangreenleaf/b206d09c587e8fc6399e which is a really good start.

All of the conversions of CamelCase to snake_case, or plural to singular are all strictly rails. AFAIK, the only thing Ruby cares about is capitalizing classes, maybe.

The rails guides are not references. They're tutorials.

An example of the thing I'm having trouble with:

I'm having things like "it says it's missing foo_bar_bazes" but "foo_bar_bazes" never occurs in my code, why does it think that it SHOULD?" The answer in this particular case was that there was a FooBarBaz or  something, and that Rails decided that there obviously should be a foo_bar_bazes sql table, which I never created. Rails was RIGHT, there needed to be a sql table, but it took me like 4 hours to figure out what it was complaining about, and where it thought "foo_bar_bazes" needed to live, and why it should be foo_bar_bazes and not FooBarBaz, or FooBarBazes or foo_bar_baz, or any other of a number of possible things... It took another 4 person hours to figure out how to get migrate to correctly do the things I needed, because it converted Camel to snake in ways that I didn't expect.

[Walter Lee Davis]

> On Mar 27, 2018, at 3:39 PM, Brian Postow <bpo...@gmail.com> wrote:
>
> No, I'm pretty sure that everything I'm looking at is strictly rails. A friend pointed me at: https://gist.github.com/iangreenleaf/b206d09c587e8fc6399e which is a really good start.
>
> All of the conversions of CamelCase to snake_case, or plural to singular are all strictly rails. AFAIK, the only thing Ruby cares about is capitalizing classes, maybe.
>
> The rails guides are not references. They're tutorials.
>
> An example of the thing I'm having trouble with:
>
> I'm having things like "it says it's missing foo_bar_bazes" but "foo_bar_bazes" never occurs in my code, why does it think that it SHOULD?" The answer in this particular case was that there was a FooBarBaz or something, and that Rails decided that there obviously should be a foo_bar_bazes sql table, which I never created. Rails was RIGHT, there needed to be a sql table, but it took me like 4 hours to figure out what it was complaining about, and where it thought "foo_bar_bazes" needed to live, and why it should be foo_bar_bazes and not FooBarBaz, or FooBarBazes or foo_bar_baz, or any other of a number of possible things... It took another 4 person hours to figure out how to get migrate to correctly do the things I needed, because it converted Camel to snake in ways that I didn't expect.
>
>

In that case, I suspect that you really ought to follow a single tutorial all the way through, even if you do know how to program. I really recommend the (free to use online) https://railstutorial.org by Michael Hartl. We use this at Penn for all new programmers, regardless of their existing experience with programming or Ruby or Rails. The last time I did it, it took me about two days to go from end to end (I take it over each time there's a new version, so I can advise the people I'm on-boarding). I've been using Rails professionally for over ten years, and I still learn things from it.

Following that exercise all the way through will give you an excellent tour of the many ways that Rails extends the Ruby language to make your day-to-day experience easier and faster (once you know the tricks).

You really won't get very far in Rails (with all your hair in place) if you don't follow the conventions it expects you to. There are ways around everything (self.table_name = 'BadLegacyTableName', for example, or self.primary_key = 'somethingRailsWontGuess'), but you can come to those after you learn what it expects by default. Being able to back a table with a form using an empty class of the proper name doesn't come for free (you have to follow the conventions to get it). If you're used to doing everything from scratch, you may not expect that to work, or know where to look when it doesn't.

Walter

> On Tuesday, March 27, 2018 at 1:09:46 PM UTC-4, Hassan Schroeder wrote:
> On Tue, Mar 27, 2018 at 6:52 AM, Brian Postow <bpo...@gmail.com> wrote:
>
> > I'm an experienced programmer, who's starting to use Ruby on Rails for the
> > first time. I need some documentation that JUST explains how variable names
> > are manipulated. Things I need to understand:
>
> The questions you're asking make me think you're conflating "Rails"
> and "Ruby". You might want to start at https://www.ruby-lang.org/
> with the "Ruby in 20 Minutes" and "Ruby From Other Languages"
> sections first.
>
> Aside from that, have you looked at the Rails guides? They might
> clarify some of your Rails-specific questions.
>
> http://guides.rubyonrails.org/
>
> HTH!
> --
> Hassan Schroeder ------------------------ hassan.s...@gmail.com
> twitter: @hassan
> Consulting Availability : Silicon Valley or remote
>

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/8df611da-76f3-4c75-b128-6bf2d6586c45%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[nanaya]

On Wed, Mar 28, 2018, at 04:39, Brian Postow wrote:
> The rails guides are not references. They're tutorials.
>
> An example of the thing I'm having trouble with:
>
> I'm having things like "it says it's missing foo_bar_bazes" but
> "foo_bar_bazes" never occurs in my code, why does it think that it SHOULD?"
> The answer in this particular case was that there was a FooBarBaz or
> something, and that Rails decided that there obviously should be a
> foo_bar_bazes sql table, which I never created. Rails was RIGHT, there
> needed to be a sql table, but it took me like 4 hours to figure out what it
> was complaining about, and where it thought "foo_bar_bazes" needed to live,
> and why it should be foo_bar_bazes and not FooBarBaz, or FooBarBazes or
> foo_bar_baz, or any other of a number of possible things... It took another
> 4 person hours to figure out how to get migrate to correctly do the things
> I needed, because it converted Camel to snake in ways that I didn't expect.
>
>

http://guides.rubyonrails.org/active_record_basics.html#naming-conventions

By default, Active Record uses some naming conventions to find out how the mapping between models and database tables should be created. Rails will pluralize your class names to find the respective database table. So, for a class Book, you should have a database table called books. The Rails pluralization mechanisms are very powerful, being capable of pluralizing (and singularizing) both regular and irregular words. When using class names composed of two or more words, the model class name should follow the Ruby conventions, using the CamelCase form, while the table name must contain the words separated by underscores. Examples:



http://guides.rubyonrails.org/active_record_migrations.html#creating-a-migration

Migrations are stored as files in the db/migrate directory, one for each migration class. The name of the file is of the form YYYYMMDDHHMMSS_create_products.rb, that is to say a UTC timestamp identifying the migration followed by an underscore followed by the name of the migration. The name of the migration class (CamelCased version) should match the latter part of the file name. For example 20080906120000_create_products.rb should define class CreateProducts and 20080906120001_add_details_to_products.rb should define AddDetailsToProducts. Rails uses this timestamp to determine which migration should be run and in what order, so if you're copying a migration from another application or generate a file yourself, be aware of its position in the order.



http://guides.rubyonrails.org/association_basics.html#detailed-association-reference

When you declare a belongs_to association, the declaring class automatically gains five methods related to the association:

...

When you declare a has_one association, the declaring class automatically gains five methods related to the association:

...


Not sure where you got the idea it's not references.

Oh and here's the documentation for autoloading mechanism (re: "Given a name of a given form, what kind of thing does RoR think it is and where is RoR looking for it?"):

http://guides.rubyonrails.org/autoloading_and_reloading_constants.html

[Brian Postow]

by "not references" I meant it's way too verbose for what I need. The rails guides are meant (or appear to be meant) to be read cover to cover. I need something where I can looks a specific thing up.

It's the difference between http://ruby-doc.com/docs/ProgrammingRuby/ and http://ruby-doc.org/core-2.5.0/ 

Both are useful for learning Ruby, but if you want to just look something up, it's much easier to look things up in the core docs than in the book... But you're not going to read the core docs front to back.

I want the core docs. the rails guides are the book.  

[Marco Antonio Almeida]

Hi Brian,

Here is an API reference for Rails: http://api.rubyonrails.org/. You need to check on the Rails version that you're using though, so you don't fall into missing or deprecated methods.

There you can find an updated quick reference to the things that you probably dealt with like has_many, belongs_to and so on. But just like our friends here mentioned, and the example you gave us, this quick reference won't help you understand that a parameter :foo_bar_bazes references a class called FooBarBaz. Getting familiar with the Rails way on doing things will definitely help you to go through that.

Kind regards,

// Marco

--

You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/c09de860-f182-43d2-b980-5b42fdd4d0c8%40googlegroups.com.