Another scenario is when an acquisition occurs for the data a company has collected and so the codebases are quietly retired. In that situation there's still some value in paying down some technical debt - security updates on libraries and whatnot - but there's a point at which the decommissioning effort becomes the primary driver.
That's the truth. I had a thing come up the other day where a client wasn't including a content type header and thus the body was being interpreted as application/x-www-form-urlencoded. Rack middleware to the rescue on that one.
I was always disappointed by rails:update - look at all these crazy changes, I can't do all this stuff! - until I figured out I was using it the wrong way. A good way to use it is to run it in a different branch and then scroll through the diff, picking out items that you want to update. This lets you pick and choose and do even that incrementally, so you can do some easy ones first (like removing unnecessary MIME type registrations) and then move on to more complicated ones.
What I've learned from Ruby is to favor functional programming concepts - minimize side effects, isolate state mutation, etc. Ruby is definitely OO, but when my Ruby code is more functional it's less buggy, easier to understand and move around, and generally less convoluted.
Yes, although many changes are performance optimizations and other under-the-covers sorts of things. Here are the changes for 2.5 which if tradition holds will be out on Christmas:
In the morning, usually setting things up for whatever operations are scheduled for the 0800-1200. In the evening, squaring things away from whatever we did that day and maybe prepping for night helo ops.
That an interesting watch rotation to stand. At first I dreaded that one because you get less sleep. But the upside is that 0400-0800 is a quiet time aboard a ship, and 1600-2000 things are usually winding down as well.
And if you're standing that watch that means you're not standing port and starboard (i.e. 4 hours on 4 hours off) so, could be worse!
More generally I get worried about my ActiveRecord objects getting too bulky and business logic getting all wound up in post-transition callbacks and such. But that's something that can be managed with service objects and being disciplined about triggering state changes.
https://youtu.be/EQnaRtNMGMI?t=108