Introduction If you鈥檝e worked with Rails for some time, you鈥檝e probably seen performance issues that did not make much sense at first. One of the usual suspects is the N+1 query problem. It is easy to miss, and it can quietly slow things down as your data grows. What is the N+1 Problem? In simple terms: You load a list of records (1 query) Then Rails runs one query per record to fetch associated data A quick example: ...
I was recently working on a Sinatra-based web app. Some backend pages used Tailwind CSS, so I had to compile Tailwind assets after every change. I was deploying the API with Kamal, and every time I deployed, I had to run the Tailwind build command by hand: bundle exec rake tailwind:build That got old pretty fast, especially when I was deploying often during development. Automating with Post-Deploy Hooks I wanted to automate this so Tailwind assets would build after every deployment. After digging a bit, I found post-deploy hooks in Kamal. ...
馃毃 The Problem Everything worked fine locally, but CI kept failing. I was working on a Rails application that used two databases: A primary database (fully controlled by the app) A secondary database (owned by a different application) The catch was this: 馃憠 The secondary database was read-only from my app鈥檚 perspective. Locally, this was not a problem because the database already existed and had the expected schema. But in CI: ...
馃毃 The Problem I was working on a Rails app that used Slack for two main things: Mapping Slack users to our HR app Sending notifications to Slack users or channels Everything looked fine locally, but in staging and production Slack rate-limit errors (429 Too Many Requests) started showing up: Mapping users required fetching the Slack user list repeatedly Sending notifications in bulk triggered multiple API requests in a short time Some requests failed, causing unreliable notifications and mapping 馃攳 Root Cause Slack has strict rate limits for each API method. ...