Re: [Rails] Rails conventions

[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

On Tue, Mar 27, 2018 at 11:48 PM Brian Postow  wrote:

> 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.
>
> On Tuesday, March 27, 2018 at 5:18:29 PM UTC-4, nanaya wrote:
>>
>>
>>
>> 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
>> MMDDHHMMSS_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
>> 2008090612_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
>>
> --
> 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 

Re: [Rails] Rails conventions

[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.  

On Tuesday, March 27, 2018 at 5:18:29 PM UTC-4, nanaya wrote:
>
>
>
> 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 
> MMDDHHMMSS_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 
> 2008090612_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 
>

-- 
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-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@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.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails] Rails conventions

[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 
MMDDHHMMSS_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 2008090612_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

-- 
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-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-talk/1522185467.2857204.1318226216.161518C4%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails] Rails conventions

[Walter Lee Davis]

> On Mar 27, 2018, at 3:39 PM, Brian Postow  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  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-talk+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-talk@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.

-- 
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-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-talk/DE5AD2CF-FA0E-4511-B04A-89F63C6EFADB%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails] Rails conventions

[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.


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  > 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-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@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.

Re: [Rails] Rails conventions

[Hassan Schroeder]

On Tue, Mar 27, 2018 at 6:52 AM, Brian Postow  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.schroe...@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-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rubyonrails-talk/CACmC4yBxd4XW1FbFP4Ts5GtyBjBRp_ifs5sHTN_SshsF1xp3qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.