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:
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.
I actually don't like rails' convention over configuration school of thoughts. It makes everything implicit. For any large rails app it's difficult to reason about how things are working, unless you learn all the conventions by heart (by the way, these conventions don't seem to be documented well)
I'm a Rails developer and I'm coming to feel this way as well. I agree with most of what's in the Rails Manifesto except the convention-over-configuration thing. Too much "magic" happening. Magic's cool, but I need to know why a certain thing works or why it doesn't work.
Rails is the only environment in which I've routinely found myself utterly stumped. Not because it's hard, because it isn't. But the thick layer of "magic" makes it awfully hard to debug sometimes.
Yeah, that's gotta be one of my biggest complaints after years of working with Rails. Eventually you sort-of memorize the conventions and can relatively accurately guess where a file lives, until someone decides to get clever and put things in a weird place.
It also implicitly discourages you from asking yourself if you should be accessing the thing you are. IMO a lot of the tight coupling in Rails codebases begins with being able to grab literally anything and use it with no one the wiser unless the read that specific line of code.
newsat13 wasn't complaining about using conventions. newsat13 was complaining about how Rails uses black magic with conventions.
I can't speak to Rails, but I've worked in other codebases that used reflection to dynamically attach different pieces of code together. It was hard to trace code because I couldn't do a search for the value being generated nor could I use the static analysis to find the value. I had to manually trace through the whole stack to find the bit of reflection that was generating a value.
Rails codebase tends to have a problem of only containing information about how something is supposed to be used and very little about how things fit together or why particular choices where made.
I think he's talking about people using Rails worrying too much, not the people writing the Rails framework.
Just as an aside, I totally agree that we spend too much time worrying about this sort of thing. I'm definitely guilty of this myself. I think it's probably born out of the heavy use of "convention over configuration" in Rails; whenever I try to do something, I always think "Am I following convention here?". My instinct now usually tells me "probably not, but just get it done and worry about that later".
It's crazy to me that this is even controversial. The fact that I have no idea where code is coming from in a rails codebase is by far the most aggravating thing about the whole ecosystem.
Safety aside, I find going back to “guess the source of the meta magical pattern-named method” intolerable these days. Onboarding to, taking over, or pinch-hitting in a Rails codebase is miserable unless it’s tiny and perfectly maintained by developers with excellent judgement and taste—and of course this is almost never the case.
I think Rails developers seriously, seriously fetishize those six actions to the detriment of several other concerns.
First, not everything your app will do is conveniently understandable in terms of resources, just like not everything code does is conveniently understandable in terms of operators. We have, thankfully, largely killed operator overloading and replaced it with functions. Why regress on function naming in our controllers? This is really a paypal_callback, not a PUT on the Paypal "resource", which doesn't even exist and if it did would tie across authentication, billing, and stats subsystems. (What does a PUT on Paypal even mean, anyhow?)
I also get hives when I think about including Rails default routes -- which are programmer-optimized, not user-optimized -- in publicly visible places, where they will get picked up by search engines and seen by copy/pasting users. example.com/categories/1/cards/5 is a part of your user interface... and it sucks. example.com/bingo-cards/holidays/halloween is superior in just about every conceivable way.
I recently began working with Ruby on Rails after years in ASP.Net and I still have to refer to the API, Guides, and documentation so I consider myself an amateur. I'm having to get used to programming "better" since I no longer have the assistance of a compiler to catch these type of errors.
As you probably know, Rails is about convention over configuration. This increases the initial learning curve but speeds up development once you understand the conventions. I read Agile Web Development with Rails and was able to make it over the initial hump of "what..why is this capitalized and this plural and the singular" stage.
I wonder if it's because Rails creates such a specific set of expectations that when you actually try to do something without it you run into problems. "Oh, that's only a rails thing? I thought that was a ruby thing..."
Ruby's monkey patching convention might make this worse.
It sounded to me as if you believed this was typical for a rails site. Maybe I read it wrong, but it isn't typical for a rails app that I've ever done.
I've been a Rails dev for a long time. I've tried a bunch of things and keep coming back to it for the same reasons as you. I'm incredibly productive in it.
For the longest time, my primary complaint has been a lack of documentation/conflicting information when you break from convention. It can be extremely challenging to find/understand the "blessed" way of doing things. Thankfully, ChatGPT is extremely good at providing a starting point for this stuff.
The magic stuff's awful. Any time you have to dig into a mothballed Rails codebase from a version either older or newer than what you're used to, or with a bunch of Railsy magic gems that aren't in your usual toolkit, it's hell. I'd rather let the computer tell me what stuff is and where it's defined than memorize a bunch of magic prefixes.
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