RoR--more impressions

I've almost finished the Rails for Zombies tutorial and feel like I have a better grasp of how the parts of Ruby on Rails fit together. However, I'm still a little intimidated by the huge number of folders and files. So far, I understand the basics--models are used to access the database, views are for displaying content to the user, controllers are for taking data from the models and processing it so that it can be displayed in a view. Also, there are routes, which can recognize a URL and send them to the appropriate controller action. Though I understand how these (mostly) fit together, recognizing exactly what needs to be added to each model, view, or controller in order to get them all talking to each other is a little more complicated and something that I think will get easier with practice. I am hoping that having the group meeting over the weekend will be helpful in solidifying how all the pieces fit together.

As I mentioned in my previous post, the syntax of RoR is not really similar to other languages that I've used, so it's taken some getting used to. One thing that was tripping me up was the use of colons in the syntax. Sometimes I would see the colon before a word (such as ":id") and then I would see it after a word (such as "id:"). The tutorials were not very specific about these differences (other than stating that ":id" was a symbol, which I already knew) so I did some googling and discovered that having the colon before the word allows you to access the symbol while having it after indicated assignment. Example with a hash:

cars = {make: "Honda", model: "Civic", color: "Silver"} #creates the hash, assigning a value to each symbol.

cars[:make] #returns "Honda"

So it is little things like this that I have to pay attention to in order to fully understand what is going on in the code. I also found that RoR is very "convention oriented" (it follows convention over configuration in an attempt to reduce the number of decisions that have to be made by the developer). In other words, there are quite a lot of conventions about how parts are named and used, which makes it easy to connect everything together--if you can remember exactly what the convention specifies. In many ways, the idea of using convention over configuration makes sense because it simplifies and code and makes it easy to remember exactly what something is called. For instance, if you have a class in the model called "Post", then there will be a database table called "posts." Then you can reference this elsewhere in the code without having to rewrite things the way you would have to do if you named the table "blog posts", for instance. However, I wonder if this use of convention reduces the flexibility of the code. Personally, I haven't had an issue with a lack of flexibility, but I'll have a better sense of this once I have a little more experience.