To clarify, while a dependency's API's should be implicitly covered with other tests, there's something about a "simple" test that would break and point the finger at the culprit without any indirection.
"Upgrading this dependency may not break your application, but there was a change that affects the API's you rely on."
Also kind of dig anything that adds explicit friction/overhead any time someone chooses to add in a new dependency.
Outside of avoiding dependencies, does anyone have any great strategies for managing dependency updates?
Have been wondering lately about the idea of adding "Canary" tests for each dependency that test the API's used from that dependency.
That idea has plenty of problems/challenges, but it's the only option I've thought of experimenting with to reduce the friction/risk of dependency updates.
Frictionless Generators is available at 40% off via PragProg this week alongside some other great Ruby/Rails books.
https://techhub.social/@pragprog/114382071590290902
TIL: Some servers' `tzdata` only include canonical time zones, and `ActiveSupport::TimeZone` wraps `tzinfo` which uses the stystem `tzdata`. So linked/legacy time zones like "US/Eastern" will be considered invalid instead of being converted to canonical equivalent.
This can be obscured when the problem doesn't occur in dev.
So when accepting time zone values from external systems, explicitly include the `tzinfo-data` gem to ensure support for recognizing non-canonical time zone identifiers.
Had a really fun conversation about my meandering and relatively broad career path in consulting, SaaS, writing, and all that with @jeremysmithco and Jess on IndieRails.
Hadn't ever really thought about how it all connected until they asked. https://www.indierails.com/53
Ruby 3.4 introduces some changes to the display of backtrace lines.
So if you've got any code that parses backtraces with regular expressions, you'll likely need to plan for some updates to the parsing logic when upgrading.
Mike Perham on his decision to sponsor Hanami for $12,000
https://www.mikeperham.com/2025/01/17/sponsoring-hanami/
Discussions: https://discu.eu/q/https://www.mikeperham.com/2025/01/17/sponsoring-hanami/
Tons of great replies here on upgrading Rails versions. Many are more long-term strategies to mitigate the difficulties of upgrades, but it all helps.
@davetron5000 Yeah. That's definitely been a part of it, unfortunately. But it's also driving home the value of web standards and no-build being the only reasonable long-term bet.
@davetron5000 This all tracks with what I strive for. In the current case, I'm mostly just trying to get the various apps _to_ this point where it becomes much more manageable simply by staying ahead of the updates.
Just got Fireside from 5.2 to 6.0, and we're aggressively upgrading it, and the others are 7.1/7.2 on their way to 8.
@esparta I've had mixed experience with dual-booting, but that was on some seriously-neglected codebases. Will definitely have to give it another try.
@tcannonfodder Just lots of reading the upgrade guides, creating a list of anticipated challenges or areas that will require additional effort.
Then bare minimum gem upgrades to get it to boot and have the tests run.
Run `app:update` letting it make all the changes it wants and comparing the diffs and making notes and reviewing the diff between Rails versions.
Then discarding all of that and manually going through the resulting checklist based on how all of the discovery panned out.
Anybody have any secret/amazing Rails upgrade strategies that have served them well?
Have done a lot, but it's always been just infrequent enough that I've never tried to streamline the process.
Upgrading 3 separate apps across multiple versions of Ruby and Rails the last couple of months has me thinking there has to be some good tactics that I just don't know about.
Of all the Rails-learning I've done, going spelunking in the source code has without a doubt been the most educational in terms of leveling-up true understanding.
To have someone like @kaspth provide a guided tour sounds amazing. Highly recommend taking him up on this. https://lu.ma/dv5yvj4n
Since acquiring Fireside, we've been super heads-down on infrastructure and upgrades. It's a tedious slog due to the inter-connected nature of dependencies (Rails, Ruby, Gems, Redis, Postgres, Ubuntu, Capistrano, etc.)
But damn it's rewarding once things start untangling and the updates ship. Performance improves, subsequent upgrades become less tedious, and the security updates help improve your sleep!
The more Rails apps I've worked on, the more I strive to embrace two principles:
1. Use as few external dependencies as possible. (Front-end or back-end.)
2. Aggressively stay current on dependency upgrades.
The cost of adding a dependency into a stack has little to do with the up-front work of adding it.
The real cost is the long-term commitment to safely performing upgrades on a regular basis so you're never in a bad spot.
As far as I can tell, there's still no way for this to help with the readability of pull requests (and probably shouldn't be a way for security reasons), but it definitely creates a more pleasant experience locally which can reduce some of the friction of writing the description/notes for the pull request by having easy access to the diff locally.
TIL: `rails credentials:diff --enroll` (and `--disenroll`)
Makes local diffs of encrypted credentials files display as diffs of the un-encrypted text instead of diffs of the encrypted gibberish.
This helps reduce a lot of the pain of determining what changed in credentials files for merging context or navigating merge conflicts.
And, while I'm still becoming familiar, it presumably falls back to diffs of the encrypted files in contexts without access to the keys. (i.e. GitHub web interface.)
It’s only been a couple of months with Fireside, but it’s cementing two things I’ve believed for a while.
1. I prefer to buy a small and profitable SaaS app rather than start from scratch again. A running start helps.
2. I prefer not to be solo on the front-lines and in-the-code. The right partners working in the business day-to-day makes a world of difference.
Neither is set in stone, but can’t imagine starting from scratch while also being solo ever again.
@Kilian Probably something like that. :) But I think it’s mainly about having a more positive view of one’s own product.
