> It is the sort of thing that can be a pain if you don't know it, but can be learned quite easily
I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation). Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
Bundler is cool, but even with strict versioning, setting things up for the first time is no walk in the park. I won't blame rails for that though, that's clearly more of an ecosystem problem. A bigger problem than versioning though (in my eyes anyway), is when plugins follow this 'rails-way' of doing things magically, and leave no clear way to troubleshoot problems when they arise (devise, I'm looking at you).
I too find the rails guides and rails tutorial to be immensely helpful, but it's more because I would literally be completely lost without referring to them every 5mins, than because I find them terribly insightful. I know the django docs aren't really that much better, but since I can usually work my way around a django project without referring them as frequently, I guess my standards for them is lower? Same could be said for a lot of their plugins, because again, at least there I have been able to fall back on 'self-documenting code' most of the time.
I do think rails is pretty cool, and I could see why it got the praise it did, but I would probably only use it on small projects that involved only a handful of people from the get-go, because I would feel bad dropping a newbie onto a mountain of legacy rails code.
>>I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation).
I have been doing rails every day for about two years now, working on a moderately large (200k loc) app, and we very rarely go against the "rails way" of doing things wrt to naming. Like if you have a model called Post and a model called Comment with a line that says "has_many :comments" in the post, there is a lot going on. The name of the accessor will be called "comments", it will lookup data in the "comments" table that have an fk of "post_id" and materialize a collection of Comment objects.
I find those are good conventions, they are readable, and more importantly, they are consistant across all the rails apps I will ever see. So when I write new code, or am reading code I am not familiar with, there is this whole class of things I don't need to make decisions about, since there is already this implied group understanding of the way things should be.
Now, in the time I have been doing this, there have been probably around 3-4 times when I _have_ wanted to customize those things, but it is really so incredibly rare that I would go so far as to say you wont hit a point where going against the convention is a good idea until you do this professionally, at which point hitting up apidock and finding out about the :class_name and :foreign_key options.
The places where I tend to branch out is things like custom validators, or putting a bit more architecture in then jamming everything into fat models, but fighting rails conventions really isn't something you ever want to do no matter how experienced you are with them
>> Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
I think this is where the disconnect is for me about accusations of magic. A model is a ruby class that extends ActiveRecord::Base, is named as the singular version of the table, and is put into the app/models directory. I don't find any of those things particularly magical or mysterious, but if you only use the generators then you are never forced to think about the implications of the code that is being used, so that process of learning gets pushed out until way later.
The other thing is I see it recommended quite often to skip learning ruby by itself, and just pick it up as you go with rails. I think that is terrible advice, rails uses many features in the ruby language that aren't common in other similar languages. So when you run across an api like the create_table which uses a builder pattern with blocks, it seems like a lot more magical then it actually is.
Personally, I only use generators to create migration classes, and that is just so it puts the timestamp in for me. They are really there to help beginners get going (and potentially write some boilerplate code for you, although I usually would rather only write the bits I need rather then delete all the stuff I don't need). Maybe they do more harm then good though, and people should start recommending that beginners learning the framework create files manually until they gain a certain baseline of understanding.
I agree, it's not terribly hard to pick up the basic idea, but it still doesn't lend itself to the idea of being 'self-documenting', which has always been a helpful fallback when dealing with python stuff that I encounter problems with. I guess it kinda just feels like it encourages too shallow of an understanding of what's going on, especially if for some reason I might want to tweak/customize certain things later on; it feels more geared towards giving you a fish, as opposed to teaching you how to fish (which is highlighted by the 'standard' encouragement to use lots of code generation). Even after going through the docs, it took me way too long to get even a vague idea of how to properly set up a custom model/migration without the rails generator tool. But I'll admit, that's all a lot more in the realm of personal preference.
Bundler is cool, but even with strict versioning, setting things up for the first time is no walk in the park. I won't blame rails for that though, that's clearly more of an ecosystem problem. A bigger problem than versioning though (in my eyes anyway), is when plugins follow this 'rails-way' of doing things magically, and leave no clear way to troubleshoot problems when they arise (devise, I'm looking at you).
I too find the rails guides and rails tutorial to be immensely helpful, but it's more because I would literally be completely lost without referring to them every 5mins, than because I find them terribly insightful. I know the django docs aren't really that much better, but since I can usually work my way around a django project without referring them as frequently, I guess my standards for them is lower? Same could be said for a lot of their plugins, because again, at least there I have been able to fall back on 'self-documenting code' most of the time.
I do think rails is pretty cool, and I could see why it got the praise it did, but I would probably only use it on small projects that involved only a handful of people from the get-go, because I would feel bad dropping a newbie onto a mountain of legacy rails code.