Rails is a web framework written in Ruby, released in 2004, and organised around a small number of conventions that between them remove most of the decisions a web application would otherwise require. Those conventions are the reason it is quick to start with and the reason it is confusing to debug, and both effects come from the same source.
The conventions worth knowing first
Naming determines wiring. A class name implies a table name, a file path implies a class name, and an action name implies a template. Nothing declares these relationships, which is why a file can be correct and still not be found.
The database schema is generated, not written. Migrations describe changes, and the schema file is their accumulated result. Editing the schema file directly is the mistake that looks like it works.
Configuration is by environment. Development, test and production differ in ways that are deliberate and occasionally surprising, particularly around caching and code reloading. A great many “it only happens in production” reports are this and nothing more.
Where the confusion actually comes from
Not the five boxes on the chart. Two other things, both of which run code the file in front of the reader does not mention.
The first is callbacks: code attached to a model that runs before or after saving. They are convenient in a small application and, past a certain size, they mean that saving a record does an unknown amount of work. A save that sends an email is a callback nobody remembers adding.
The second is anything inserted before the controller: middleware, filters, and inherited before-actions from a parent controller. Behaviour arrives from a file the reader has not opened, which is exactly the layer question that makes Rails hard to debug and easy to write.
Convention removes decisions. It also removes the record of them.
Where the time goes in practice
Queries, and specifically the number of them. The pattern where a loop over a collection issues one query per item is the most reliable performance problem in any Rails application, it does not show up on a development machine with twelve rows of test data, and it is visible in the logs of any environment with real ones.
The second is asset and boot time in development, which does not affect users at all and affects the working day considerably.
The useful habit: read the log for a single request. It lists every query issued and how long each took, and it turns a vague sense that a page is slow into a specific count.
Rails versions, and Ruby versions
Each Rails version supports a range of Ruby versions, and the two upgrade schedules have to be planned against each other. Attempting both at once is the usual cause of an upgrade that stalls, because when a test fails there is no way to tell which change caused it.
The order that works is Ruby first where possible, since a Ruby upgrade is generally smaller, then Rails once the interpreter is settled. The supported branches at any moment are on the release timeline.
What to learn before the rest
Enough Ruby to read a method and say what it returns, which is covered on learning Ruby. Then the request path above, then the query layer, then the test setup. Everything else is reachable from documentation once those four exist.
What is not worth learning early is the full set of conventions. There are a great many, most are discoverable at the moment they are needed, and trying to hold them all in advance is the reason Rails has a reputation for a difficult start.
The tooling that reads all this is on static analysis, particularly the security scanner, whose entire subject is Rails-specific patterns. Dependencies are on gems and Bundler, the test layer on testing, and the order to take them in on the learning path.
Questions
What makes Rails quick to start with and hard to debug?
The same thing: convention. Naming determines wiring, so very little has to be declared, which also means very little is written down. A file can be correct and still not be found, and behaviour arrives from files nobody opened.
Where does unexpected behaviour usually come from?
Two places, both of which run code the current file does not mention: model callbacks that fire on save, and middleware or inherited before-actions that run ahead of the controller. Reading the callbacks first resolves a surprising share of it.
What is the most common performance problem?
A loop that issues one query per item. It is invisible on a development machine with a dozen rows and obvious in the logs of any environment with real data, which is why reading the log for a single request is the most useful habit available.
Should Ruby or Rails be upgraded first?
Ruby first where possible, because it is generally the smaller change, and then Rails once the interpreter is settled. Doing both at once is the usual reason an upgrade stalls: a failing test has two candidate causes and no way to separate them.
How much of Rails is worth learning up front?
The request path, the query layer and the test setup. The full set of conventions is large, mostly discoverable at the moment each one is needed, and trying to hold it all in advance is the main reason the framework has a reputation for a difficult start.