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.
I've been wanting to set up continuous integration for my personal projects for a long time. It's one of those things that seems super cool and useful but a bit too nebulous for me to actually sit down and devote any time to it. This weekend I finally did it, and it was a lot harder than it should have been.
If you're building a web app with ruby on rails, there's a pretty good chance you're using the will_paginate gem to make it easy to split a long list of items across multiple pages. If you have a couple hundred items, will_paginate works great out of the box. However, once you start paginating thousands and thousands of items, you'll start to run into performance issues. I'll show you how to fix them in this post.
I learned this lesson the hard way, so you should learn from my mistakes. Don't put big fields like TEXTs or BLOBs in your main database tables. Doing so will result in a negative step change in the performance of your database one day when you least expect it. You'll think your database is humming along when suddenly your database queries that used to finish in a couple milliseconds start taking hundreds of seconds.