5 ms·

As usual, Rails is impresive framework and this update addresses and eases pains (file uploads) and streamlines work (redis and cacheing). Most people unfortun

As usual, Rails is impresive framework and this update addresses and eases pains (file uploads) and streamlines work (redis and cacheing). Most people unfortunatelly are stuck with old codebases and will have to wait before they can use something shiny like this in daily work. Last few years, majority of my work in Rails is upgrading older apps to current, for security mostly. Really great update, congrats DHH and the team.

freedomben 9y ago
It's amazing how many apps for which this is true. I've spent more time in Rails land upgrading older microservices to latest rails. It's pretty crappy work actually.
- slimed 9y ago
  I too have spent a ton of time doing this. It's a product of Rails architecture and the prevailing design philosophies in the Rails community.
- desireco42 9y ago
  I am fine with it, I do this as a service for other companies who's developers are too busy with feature work.
  - slimed 9y ago
    Being "too busy with feature work" is exactly the mindset that forces us to spend months and months of developer time every couple of years to upgrade Rails and an ever growing list of other gem dependencies.
    - desireco42 9y ago
      It is hard for managers to organize developers and to uphold for good practices. That is why I created a service so people would not feel guilty, just hire us and we take care of things for you. :)
      - slimed 9y ago
        Nice for you. Not so nice for the companies wasting their money on paying you. Yeah, managing software teams is hard. But paying contractors every year to upgrade Rails is malpractice. Can you honestly say that you are capable of going into these legacy systems with thousands of lines of code and upgrading all of their gems, including Rails, without causing regressions? Maybe for a small project your approach is okay but it doesn't scale.
        quesera 9y ago
        If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work. It's a janitorial service of sorts, and it's totally appropriate for some corps to contract it out. It allows the developers with the best knowledge of the business to focus on that, where value is created. Regressions are mitigated by a strong culture of testing.
        slimed 9y ago
        I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.

freedomben 9y ago

It's amazing how many apps for which this is true. I've spent more time in Rails land upgrading older microservices to latest rails. It's pretty crappy work actually.

slimed 9y ago
I too have spent a ton of time doing this. It's a product of Rails architecture and the prevailing design philosophies in the Rails community.
desireco42 9y ago
I am fine with it, I do this as a service for other companies who's developers are too busy with feature work.
- slimed 9y ago
  Being "too busy with feature work" is exactly the mindset that forces us to spend months and months of developer time every couple of years to upgrade Rails and an ever growing list of other gem dependencies.
  - desireco42 9y ago
    It is hard for managers to organize developers and to uphold for good practices. That is why I created a service so people would not feel guilty, just hire us and we take care of things for you. :)
    - slimed 9y ago
      Nice for you. Not so nice for the companies wasting their money on paying you. Yeah, managing software teams is hard. But paying contractors every year to upgrade Rails is malpractice. Can you honestly say that you are capable of going into these legacy systems with thousands of lines of code and upgrading all of their gems, including Rails, without causing regressions? Maybe for a small project your approach is okay but it doesn't scale.
      - quesera 9y ago
        If you know rails well and keep current, upgrading is perfectly straightforward, if uninspiring, work. It's a janitorial service of sorts, and it's totally appropriate for some corps to contract it out. It allows the developers with the best knowledge of the business to focus on that, where value is created. Regressions are mitigated by a strong culture of testing.
        slimed 9y ago
        I've spent many months upgrading legacy Rails services. One particular project was upgrading several microservices from Rails 3.1 to Rails 4. The projects made use of Rspec, Test::Unit, and Capybara. There were unit tests, integration tests, and UI tests. There were over 5000 specs in total. The project also used many gems in production to accomplish its tasks. When you are forced to uprgrade: the testing frameworks themselves, the ORM, the web framework, static asset building tools, libraries for managing file uploads, map rendering, etc, all in one go, it's nearly impossible to get it 100% right. We upgraded minor versions one by one. We read the Rails release notes and any gems that had them. Every time we bumped a Rails version we broke thousands of tests. Even after months of meticulous work we had only managed to upgrade 3 of the 4 services up to Rails 4.0, with another stuck on 3.2. Is it possible to work this way? Sure. But it's insane and costly when you let it get this bad. I've yet to work on a large Rails project on a team that outsources their upgrades where upgrading was "perfectly straight forward". It sounds like you work for a company that actually cleans house. A company like that has no need to hire OP.