Posts tagged “rails”

A month inside Fizzy turned open source code, APIs, webhooks, and AI agents into a whole toolbox of experiments.

Fizzy’s PRs reveal the architecture lessons, code review habits, and contributor specialties hidden behind the final product.

Booting old Fizzy commits one day at a time turns 18 months of interface decisions into a literal design flipbook.

Campfire, Writebook, and Fizzy show that modern vanilla CSS can power serious apps without Sass, PostCSS, or a build step.

Fizzy’s webhooks unlock dashboards, digests, SLA alerts, stakeholder reports, and plenty of useful automation around your cards.

The danger is not using AI; it is using AI with so little friction that your brain quietly leaves the room.

The Rails path to Tailwind 4 is mostly smooth, but the upgrade tool leaves a few package-manager footprints behind.

Solid Queue can replace Redis cleanly if Capistrano and systemd know how to restart it during deploys.

Rails browser guards are useful until your own mobile emulator gets blocked by the default modern-browser rules.

A Rails 7.1 upgrade quadrupled Heroku memory because Puma quietly started using every reported core.

Production-only Action Mailbox failures are easier to fix when you replay the raw email locally and reroute the broken ones.

The Rails links worth keeping close because they answer questions faster than memory does.

Rails 7 dropped the old webpacker clue Heroku used, so Yarn only appears if you add the Node buildpack yourself.

A `.railsrc` file turns every new Rails app into your preferred stack before you write a line of code.

Rails runs `after_commit` and `after_rollback` callbacks in reverse order, which is exactly the kind of detail that bites later.

Testing feels slow at first, right up until it becomes the thing that stops every change from feeling dangerous.