I'm working on the Herb Formatter and I'm wondering if there is something like rubystyle.guide for HTML+ERB?

Or is this the time to build a guide?

@cassey Great no-nonsense overview! Rails assets has always felt to me like an afterthought bolted on to Rails out of necessity. Thankfully, it feels like modern browsers are helping move past the more heavy-handed solutions.

Been navigating try to standardize all of this across multiple apps, and it’s some of the most tedious and confusing work I’ve ever done around Rails. Would have loved to have encountered this post weeks ago. 😭

Time to close so many tabs: this blog post (and talk I gave today at work) is the result of so much research.

I wrote it to solve my own problem of opening some legacy Rails app and needing to figure out what the heck is going on with the JS & CSS assets, over and over again, and then what to upgrade them to when it turns out something is broken in a way that won't let me make changes.

https://cassey.dev/rails-frontend-asset-management/

#RubyOnRails #Rails #YearOfTheBlog

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/

#programming #ruby

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.

https://ruby.social/@garrettdimon/113902710512876103

@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.