I went all in many years ago and then moved on several years ago (to different parts of the stack that I found more interesting), but here's my 2c FWIW.

The Rails Guides [1] are quite good (and much better than the API docs, even for the same topics). The "Getting Started" guide, in particular, was my first intro to Rails, and it's what convinced me to go all in — I built my entire prototype by just following along the guide, seeing what they were doing with their toy app, and then trying to whatever similar thing I needed in my app.

Coming from Python, the magic was distasteful to me, too. Rails adds a ton more magic on top — so, eventually, when I set aside Rails and just spent time with Ruby (writing scripts or what not), I realized I loved Ruby the language much more than Rails the framework (and all its baggage).

Stripping Rails down to its API-only mode (though it was a bit rough around the edges last I tried) got me closer to the Ruby of it all. Sinatra turned out to be a delightful little framework (though sadly I never got a chance to use it much). And, even though I've now moved on from Rails, I still like Ruby as a go-to scripting language — it makes it fun and easy to throw together a quick shell script or some data analysis, and it's very friendly to a functional programming style.

I guess what I'm saying is: You're not alone. Many people in the Rails community agree that there's a ton of hidden magic, sometimes too much [2]. But underneath it all is a delightful programming language.

[1]: https://guides.rubyonrails.org/

[2]: The docs for the Rails routing layer, Journey, are my favorite example of this: https://github.com/rails/journey#label-SYNOPSIS-3A

I had exactly the same problem. Recently, with the help of ChatGPT (just free version). When I didnt know anything, I just asked. The result was pretty good.

I also wrote stupid code first in my own version, and copied + pasted to chatGPT, asked it to improve it, or rewrite in ruby on rails style. And wow!! The rewrote version even went with explanation.

Beside that, you can use Rails console to test.

This was my experience and I have commented it before. The magic/convention approach is the inferred part of Rails/Ruby culture. Where is the class definition? Well, where are you invoking initialization? This question leads to a question which hopefully leads to answer is hard to play by if you’re new or just trying to squash a simple request.

The whole just fire up an interactive session or rails console is probably the last thing I want to do but probably the only way to diagnose or figure out how things are truly working. What monkey patches are in the mix, what libs override methods I set, etc.

For me, Ruby is one of those programming languages that obviously takes a different programming approach and mindset that I don’t have. I don’t think Ruby is bad but I know it isn’t the tool that fits my skill set.

A good way to explore is getting an interactive session with something like pry and exploring what methods and attributes are available that way. It sounds clunky, but it's quite effective as you frequently get to play through the entire implementation once and it pairs extremely well with TDD.

I love ruby, and find it great to use pry and irb to explore and figure stuff out.

However, many times ruby libraries will use dynamic programming and method_missing to define methods on the fly… this makes it really hard to figure out what methods are actually available.

For that reason, I try to never use method missing to define core functionality in ruby, and hate when other gems do it.

The responsible thing when you use `method_missing` is to define `respond_to` to indicate whether an object responds to a particular method. This alleviates the "is a method available" issue because you can just ask the object "Do you respond to :method_I_want_to_call?", and it will correctly inform you it does or does not. This kind of discoverability is one of the things I miss when I'm working in Javascript/TS as I have been recently - sure you can check the .method_name property to see if it's a function and then execute it but it doesn't feel as nice.

E.g.

    def method_missing(name, \*args)
      if name =~ /^has_/
        has(name, *args)
      end
      super
    end

    def respond_to(name)
      if name =~ /^has_/
        return true
      end
      super
    end

Sure, but my favorite thing to do in irb is <object I want to inspect>.methods.sort - Object.methods

This won’t work even with respond_to being defined

I also love this technique . I prefer to subtract {}.methods though - shorter to type and removes more cruft.

Hah, I am even twice as lazy as you and do '- 1.methods'. Works for 99.9% of cases.

I second this, when I was in Ruby land I used to regularly drop a binding.pry (later binding.irb) in the middle of some code i wanted to understand, and call things like `method` to see where an unrecognized method came from.

Pry is amazing for understanding code. IMO the most useful method is absolutely `some_object.methods`, but you can also improve the output a ton by always doing:

    some_object.methods - {}.methods # or some other "parent" class/object

This does set subtraction to remove all the "core" object methods from your some_object methods, so you can see just what's unique about that object. For example, comparing one of my services with a parent Service class it inherits from:

    irb(main):017:0> PaypalService.methods - Service.methods
    => [:capture_invoice_funds, :months_price, :client, :create_prepay_invoice, :order_info]

instead of listing out the 187 methods that PaypalService has that it inherits from Service and every other parent object up the line, which is usually a surprisingly long ancestor list in any Ruby on Rails class (even POROs!).

There are a TON of useful methods like this that I'd recommend getting familiar with, which makes exploration and discovery of code incredibly fast and efficient. You can find them all with the same trick: by using `methods` on any method. :)

    irb(main):043:0> PaypalService.method(:months_price).methods - {}.methods
    => 
    [:<<,                                                                                             
    :>>,                                                                                             
    :arity,                                                                                          
    :curry,                                                                                          
    :source_location,                                                                                
    :call,                                                                                           
    :parameters,                                                                                     
    :original_name,                                                                                  
    :owner,                                                                                          
    :receiver,                                                                                       
    :super_method,                                                                                   
    :name,                                                                                           
    :unbind,                                                                                         
    :comment,                                                                                        
    :source]

Some of the more relevant ones:

    irb(main):037:0> PaypalService.method(:months_price).arity
    => 1

    irb(main):038:0> puts PaypalService.method(:months_price).parameters
    req
    n_months                                                                                  

    irb(main):039:0> puts PaypalService.method(:months_price).source
      def self.months_price(n_months)
        case n_months                                                                         
        when 1                                                                                
          9.00                                                                                
        when 3                                                                                
          24.00
        when 6
          48.00
        when 12
          84.00
        else
          raise "Invalid month prepay: #{n_months}"
        end
      end

> slow, bloated RubyMine IDE

If you haven’t tried it in a while, it’s quite good on Apple’s arm chips. Doesn’t feel slow at all, and the battery hit is negligible.

Using Rubymine on my M1 Ultra Mac Studio is a wonderful experience. Would not trade it for any other environment.

I’ll second this. Using RubyMine on an M2 Pro, feels faster than Vim… y’know… the vanilla non-bloated one. :P

Maybe when I can afford one. It's slow on my machine.