Good luck with those very brittle specs. I have fixed so very many utterly broken tests due to poor spec maintenance mainly due to really poor fixtures. The problem with fixtures is that they do not complain when things go sideways whereas factories are built on top of actual living objects and thus can be validated.

You're generally trading speed for correctness in my experience. There is a time and place, of course, for this tradeoff, but we know how to parallelize specs and make test, in general, faster. Correctness is a whole different story.

Using factories doesn't mean you need to persist everything to the DB on every test.

If you're using FactoryBot for example, you can use `build(:taco)` to instantiate a Taco without persisting it to the DB. If you use `create(:taco)` instead, then yes, the Taco will be saved to the DB, as well as all its associations (if any). This can of course bloat up your test execution time if you're doing this kind of instantiation + persistence on every test.

FactoryBot docs generally use `build` in their examples, as this should be the default build strategy used for most tests, while `create` should only be used on cases where you actually need to interact with the DB.

I love ruby having used it since before Rails, but it seems weirdly susceptible to the "with great power comes great responsibility" issue. Dynamically typed + the "don't disallow stupid things or you'll disallow clever things" mentality, maybe? Early adopters like _why who could actually handle it having a huge influence? Dunno.

I've worked with some devs who were not old battle-scarred greybeards who jumped on EVERY rspec feature because they were there and in a misguided attempt to DRY their test code well beyond reasonable limits.

So I feel you here.

But FactoryBot does allow fixture-like speeds with in-memory .build()'ing. Too few people use it, and too few have succumbed to a preponderance of tests being full-on integration style.

Ruby (and Rails, and rspec) all IMO require a lot more good guidance and wisdom on what NOT to use than other ecosystems I've used.

> For that matter, rspec itself is also a thoroughly unnecessary cargo-culted dependency when Ruby and Rails already bundle perfectly-serviceable, simple test frameworks

I think people developing professionally and working with large code bases, reach pretty fast all the limitations of minitest. IMO, Minitest is great to test small libs, but as soon as you need to refactor a lot of specs or use other stuff like Factories, then rspec is the tool. No cargo-culted. It is just the best and more complete option.

I too now prefer fixtures. Such a joy to work with them.

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.

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

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.

An almost 20 year old demo from the creator really doesn't address the issue of community resources. Any application of minimal complexity needs to solve problems that demo doesn't begin to address, and beginners need access to resources to guide them in solving those problems.

Not to mention that Rails was the language-de-jour for most bootcamps between 2012 and 2017 or so. The problem was running into developers who only knew Rails, not finding ones that didn’t know it at all.

Also Railscasts.

Some how nostalgic for those plain invert-colours buttons that rails used to have. Also DHH's iconic "whuups!" every 2 minutes is pretty funny to relive.

This, IMO everyone considers Rails as a solid & production ready framework that stood the test of time.

Unfortunately they slept on front-end for too long but seeing a resurgence with a few startups.

I think Mastodon is actually using it.

Rewriting the entire asset pipeline like 3 times since Rails 3.x has really killed my enthusiasm for using Rails for server side rendering.

Some googling tells me that isomorphic SPA means the same page can be rendered server side or client side. Is that what it means to you? It's my first time encountering the term. If so ... people were doing that in react??

For anyone else out there confused: Next.js != Nest.js.

To write web app in golang and write mostly SQL by hand isn't that cool. Yes sometimes it is important, sometimes you should. But ActiveRecord is just a dream, that quite often people even forget how hard was the life before it.

> it's scaleable.

That is debatable. Both GitHub and Hackyderm are large-scale Rails deployments, and both share a DevOps engineer (Nóva) who I've heard complaining about Ruby DevOps at least once. Twitter was forced to abandon Rails (being the poster child for Rails at the time).

That ecosystem is crumbling too, unfortunately.

Where, for example, in 2015 any SaaS or API would provide a gem (lib) to interact with it, today it's no longer the case. Modern PSPs, storage, search engines, etc almost all lack an official gem. Often lack even a third party one.

And where back in 2015 there were popular systems in Ruby outside of rails, all those are crumbling and/or gone. Jekyll is no longer the go-to static site manager, Chef and Puppet no longer the obvious devops tools. And Ruby is completely absent from emerging technology (AI, blockchain, WASM, data science, etc).

I'm afraid Ruby is becoming a legacy language and Rails' will be a legacy framework soon. Where the bulk of the Ruby jobs are to keep old stuff running and maintained. Afraid, because I'm still primarily Ruby developer.

> need incredible amounts of tests to compensate for the lack of compile-time type checking

can you explain this a bit more? it seems to me that test coverage and typing solve different problems.

What is an example of a framework that offers a space for business logic?

> But my biggest gripe is how Rails lacks a space for business logic.

You can literally create a directory called app/my_actual_app and put all your business logic in there, Rails will even autoload it for you.

IMO it’s the sudden change from the “we’ll hold your hand every step of the way and offer tools and workflows for everything” web part (controllers, routing, ORM) to the “go and build your goddamn app” dealing with business logic. So many (especially new) devs try to stay in the cozy zone of having a nice name for everything at all costs, so they try to cram everything into “services” and “decorators” and “interactors” (yuck) and they’ll build business logic out of callbacks on ActiveRecord models and overload the poor things with dozens of “concerns” instead of, you know, going and building a goddamn Ruby app.

Re: DDD and business logic, I’d recommend reading https://dev.37signals.com/vanilla-rails-is-plenty/

You've got the wrong impression of what ruby optimizes for. It's not "mainly that code should be beautiful English prose" -- which I would venture the closest you'll get for that goal is AppleScript -- but rather, quoting Matz "Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby."

More here: https://www.artima.com/articles/the-philosophy-of-ruby

> speed comes from code re-use (mostly gems)

> Once you get experienced in rails, you primarily glue things together

Both of these are equally true for most other languages with mature ecosystems. IMO the speed of Rails development reflects the speed of Ruby development in general. The standard library has everything, all kinds of little methods for all kinds of little things. Combine that with ActiveSupport extensions and you can do everything.

  Date.today + 3.years + 2.days
  234.in?(2..235)
  [1,2,3].all?(&:odd?)

That's interesting. I remember having to defend my using ruby to other programmers around that time. I always loved it, and all the hate seemed to be centered around "it's too slow". No one ever brought up twitter being down, explicitly, that I can recall. Perhaps that's what they had in the back of their mind though? It's been a bit of a mystery to me why people passionately hate on ruby and IMO dismiss it out of hand. It's so nice to program with.

If you know what Rails is doing then it isn’t hard to reason about. This comes with time/experience & reading Rails source.

Magic is a beautiful term for what Rails does, because just like a magician’s tricks, it’s possible to have a full understanding of what’s going on. It’s not as if Rails acts randomly.

Rails has always been fully open source. If you didn't understand something you simply looked at the Rails source code. At the time it came out most people were using .NET or Java which were largely closed source and PHP which was open source, but there were no real frameworks at that time. CodeIgniter and Cake came out in the couple of years following and were both immature in comparison.