Making improvements to a four-year-old Ruby on Rails project was much more difficult than I ever anticipated...

After developing PHP, Node.js, and Java apps, old and new, I noticed they all have a similar development workflow: there's a package manager for libraries, a version manager to switch runtimes, and a local development server to run your app. How hard could it be to do the same with Ruby?

I'm sure it could've been simple, but the new Apple Silicon architecture (ARM64) really threw a wrench in things. Some packages anticipated the old Intel chip architecture, and it wasn't as simple as upgrading them. I wish I could elaborate more, but there were layers to the issue, and I didn't know how deep to go. I could easily waste time debugging the wrong thing.

After implementing the solutions posted on GitHub for these problematic dependencies (nokogiri, ffi), when I was finally able to successfully run the Rails server, I didn't get a typical stack trace, but instead a random ungoogleable hexadecimal error that told me nothing.

So, I need to run a four-year-old app written in an unsupported version of Ruby with very old dependencies on a new architecture that has barely been around for two years on a stack I have no experience with. What now?

In my online search for answers, I discovered Ruby on Mac, a paid script that promises to unfuck your setup and get Ruby working on any MacBook. Frankly, it sounded like a scam because it felt like I was paying for information that is freely available on the internet.

However, it was $20. When considering my six-figure salary, I've essentially spent thousands of dollars going nowhere.

It didn't work right away due to an issue with how my Homebrew was set up, so I emailed support and got a response quickly with some suggestions, one being to upgrade to a higher tier of the script that includes a reset script. I went with the ultimate package, which was a little over $100, but you get 30-minutes of consulting to help upgrade old projects (my exact dilemma). None of my friends are Ruby developers, so I figured if the reset script doesn't work, I have the consultation to fall back on.

The reset script did its thing for 10-15 minutes, conveniently making backups of my existing configuration files and such. It was time to try running the app again. At this point, my expectations were pretty low. I run the Rails server expecting nothing new except new errors, but instead I was pleasantly surprised to see that it worked!

This experience really opened my eyes. As developers, I think we become conditioned to expect all solutions to be free, but there is a market for niche problems with complicated solutions. Many of the solutions I came across online were relatively old or had a ton of variables involved that may or may not have applied to my situation. It was an endless goose chase.

Productizing the knowledge of setting up Ruby on Mac is brilliant because the author was able to offer support, detailed documentation, the source code, and other things you would not expect from a random tutorial online. A lot of free knowledge is thankless and unpaid, which often means it won't be updated or maintained, and you likely won't get help in a timely manner.

We should all spend less time configuring, and more time building. Don't get stuck in the trap of doing everything yourself, especially if it takes you away from things that are more valuable to you. In this case, I am a Node.js developer who doesn't want to spend any more time on this Rails app than I have to.

Consider me satisfied!