When I first started making Ruby on Rails apps, the choice between Postgres and MySQL was not as clear as it is today. Postgres has emerged as the clear winner for Rails developers, and I recently decided to update my Rails apps to use Postgres instead of MySQL. This was a problem because I had already paid for several years of MySQL RDS reserved instances (RIs) and Amazon Web Services did not allow me to change those instances to Postgres through the web interface.
My mom's computer was running pretty slowly, so she asked me to troubleshoot it and try to find a way to speed it up. I checked the activity monitor on her computer and found that her hard drive's disk usage was often pegged at 100% while her CPU (central processing unit) and RAM (random-access memory) had plenty of headroom. Since she was using a HDD (hard disk drive), I advised her to upgrade to an SSD (solid-state disk).
I won't bury the lede here. The problem with my Capybara spec suite was that I didn't fully understand how Capybara's implicit waits worked. I made two mistakes in how I write some Capybara specs, and they ended up inflating my test time by a bunch. First, Capybara matchers don't invert themselves when they're called by RSpec's #not_to method if they're inside another method. Second, using Capybara matchers in a conditional will result in a long delay when the matcher is looking for something that will never be there.
I recently created an online version of Connect Four as part of a coding challenge. It is a SPA with the frontend written in Vue.js and the backend in Ruby on Rails 5.1. The code is available on Github in a pair of repositories. It's currently hosted on Heroku, so you can play it now.