6 ms·

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itse

Recently I upgraded a project from Rails 3.2.x to 4.0.x... 4.0.x -> 4.1.x... 4.1.x -> 4.2.x It was, and still is, a nightmare. Technically speaking Rails itself upgraded in a reasonably straight-forward way, just follow the documentation (well and a few blog posts here and there for the things missed in the official docs). But all the additional Gems, and dependencies of those Gems (and so on) made the process excruciating. Many things broke in subtle ways at runtime (no compilation, so no compiler errors) and there was no clear path to upgrade; because whilst Rails' upgrade path is documented, there's a plethora of Gems that also needed to be upgraded separately (some in contradictory manners). You might wonder why I was so out of date in the first place. Two reasons: 1. I inherited this code-base. 2. I've attempted this (or a similar) upgrade about 5 other times in the past; spending hours upon hours debugging crashes (or just weird behaviour) with enormous stack-traces where my application's own code often doesn't even appear in the stack trace. It's only now after making several failed (or rather overly time consuming) attempts I was able to come up with a "workable" upgrade path. Gems dynamically generating methods left, right and centre, Gems replacing methods of seemingly unrelated classes (when they definitely do not need to), and crazy "conventions" that hide all the actual logic make debugging any sizeable Rails project a complete disaster. Don't even get me started on the poor performance, much of which is to do with poorly designed Gems and not even the Ruby interpreter's fault. That said... I still turn to Rails when I want to get a new project (with users, database, login, admin etc.) up and running quickly. It's a shame, but in terms of development speed, it's hard to beat Ruby (and Rails). For small projects Sinatra is very solid, and Padrino is interesting - but honestly I can't wait for the day I can move to a compiled language and still achieve this sort of development speed.

heartbreak 10y ago
I hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was a success. I did end up writing about 200 unit and integration specs during the process. I'm thinking back to my days in the .Net world at BigCorp. Unfortunately I have nothing to compare it to, because we never upgraded anything from one major version of ASP.NET MVC to another. Is that a better situation?
- beat 10y ago
  A huge upgrade on code with no tests and a bunch of magical dependencies? The problem wasn't Rails there.
  - eric_h 10y ago
    There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.
    - mordocai 10y ago
      Is there anything that actually "enforces" TDD? Because if there is I want to stay away from it.
      - engineerDave 10y ago
        Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story) After that you always make sure test exist before even pondering a push of potentially breaking changes! :P
        mordocai 10y ago
        Oh yeah, I mean I always write tests for anything for work. I don't do TDD all the time though, sometimes I write the tests after the code. A language/framework that forced me to do TDD would just piss me off, which was my original point.
        engineerDave 10y ago
        I was being tongue in cheek on that one, sorry if it didn't come across that way. Although I've been a Rails dev for 6 years now, I've come to hate the TDD approach and am a convert of FP and types, & compilers a la Haskell. Because there really is no such thing as a massive change in FP IMO. Unfortunately I'm not competent enough in it yet so Rails still pays the bills.
manifestsilence 10y ago
I've found upgrade hell can apply to C#/dotnet stuff too. I work on a project that has attempted to upgrade Entity framework versions multiple times and keeps pushing it off because we get buried in compile time errors. It's a case where Microsoft supported several different paths to architect an app and then quietly deprecated half of them - database first vs. code first, POCOs vs. ObjectContext, etc. and we happened to be on the losing side of history. Compile-time errors are definitely easier to find, but the path to fixing them can be just as bad. What I really long for is good documentation and a clear path forward for each breaking change.
- douche 10y ago
  Never much liked EF... Linq-to-SQL may be dead/stable, but we're still using it, and it's pretty slick - course it is only for SQL server.
- ktRolster 10y ago
  Indeed, Microsoft's lack of commitment to APIs is what inspired Joel's famous essay: http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html IMHO .net has lost some stability with the recent packaging systems like NuGet and chocolatey; they don't really encourage stability.
- DonnyV 10y ago
  The problem is not C# or .NET. The issue is Entity framework. Either stop being scared of using SQL and use something like PetaPoco or stop trying to turn objects into records and use Mongodb and just store the damn objects.
r-s 10y ago
I have upgraded a very large Rails 3.2 app to 4.2 recently. It was about 2 weeks solid of work for my team. It was a project I inherited and when I got it the test suite took an hour to run. The biggest problem which I had was dealing with the dependencies. This project used just under 300 gems, many of them unmaintained and a few of them I had to fork to get to work with rails 3. I am very fast making things in Rails, for the most part I find it just works. When projects get to a certain size, very roughly around 50k loc, they become very slow to work on. Slow test suites and dependency hell become problems.
- barrkel 10y ago
  $ find -iname '*.rb' | xargs cat | wc -l 135106 No real problems working with this codebase. ~190 gem dependencies. Mind, most of the code is tests: $ find -iname '*.rb' | grep /spec/ | xargs cat | wc -l 96899
lmm 10y ago
The only library I've felt absolutely safe doing upgrades with is Wicket, because it makes extensive use of the type system to ensure that you only use it in supported ways: many classes are final, and even those that aren't have a lot of final methods. It can be frustrating to have to copy-paste a Wicket class when you want similar behaviour, but it works beautifully.
engineerDave 10y ago
The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some developers do actually do this but in the end I've noticed these legacy branches and gems just bitrot while the developer devotes their time to the new branch. So essentially to use the gem you have to make the SemVer API jump which then begins the dependency failure cascade dance you mention. I'm close to starting another new Rails job and I'm not looking forward to the inevitable rails rescue work on legacy codebases, yet this is the reality of a modern Rails developer. Also I think this upgrade work needs to be factored into "development time" and when you do I'm not convinced Rails is actually faster.
- busterarm 10y ago
  I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and the return output of their methods are documented.
  - engineerDave 10y ago
    Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh
    - busterarm 10y ago
jetheredge 10y ago
I've felt like any project horribly out of date is a pain to get current, Rails is no exception to that. Sure, many Rails projects have a lot of dependencies, but so do other frameworks. Sure, part of your argument is static vs dynamic, but I'm not going to join you in that argument.<grin>
wwweston 10y ago
This is exactly the past problem I've had with every Rails app I've been involved with (none of them have been from scratch) -- even during the setup process there's an immediate reckoning with gem snarls and other version issues.

heartbreak 10y ago

I hear horror stories like this, and I have one of my own. 1. Absolutely no tests of any kind 2. Over 100 gem dependencies Upgrade from 3.2.x to 4.2.x took one developer (me) three weeks of work. I don't know if that's a lot or not, given the major version upgrade and all of the gems (which were a huge pain). I've not had any problems in production reported via Honeybadger or by end users, so I think the upgrade was a success. I did end up writing about 200 unit and integration specs during the process. I'm thinking back to my days in the .Net world at BigCorp. Unfortunately I have nothing to compare it to, because we never upgraded anything from one major version of ASP.NET MVC to another. Is that a better situation?

beat 10y ago
A huge upgrade on code with no tests and a bunch of magical dependencies? The problem wasn't Rails there.
- eric_h 10y ago
  There's an argument to be made that Rails, by not actually enforcing conventions like TDD, gives an amateur/impatient developer a very high calibre footgun. Unfortunately, of course, that gun doesn't usually go off until it's handed to someone else.
  - mordocai 10y ago
    Is there anything that actually "enforces" TDD? Because if there is I want to stay away from it.
    - engineerDave 10y ago
      Yes. Being forced to push changes to production with zero test coverage, and hence zero confidence in your code on a Friday night. (true story) After that you always make sure test exist before even pondering a push of potentially breaking changes! :P
      - mordocai 10y ago
        Oh yeah, I mean I always write tests for anything for work. I don't do TDD all the time though, sometimes I write the tests after the code. A language/framework that forced me to do TDD would just piss me off, which was my original point.
        engineerDave 10y ago
        I was being tongue in cheek on that one, sorry if it didn't come across that way. Although I've been a Rails dev for 6 years now, I've come to hate the TDD approach and am a convert of FP and types, & compilers a la Haskell. Because there really is no such thing as a massive change in FP IMO. Unfortunately I'm not competent enough in it yet so Rails still pays the bills.

manifestsilence 10y ago

I've found upgrade hell can apply to C#/dotnet stuff too. I work on a project that has attempted to upgrade Entity framework versions multiple times and keeps pushing it off because we get buried in compile time errors. It's a case where Microsoft supported several different paths to architect an app and then quietly deprecated half of them - database first vs. code first, POCOs vs. ObjectContext, etc. and we happened to be on the losing side of history. Compile-time errors are definitely easier to find, but the path to fixing them can be just as bad. What I really long for is good documentation and a clear path forward for each breaking change.

douche 10y ago
Never much liked EF... Linq-to-SQL may be dead/stable, but we're still using it, and it's pretty slick - course it is only for SQL server.
ktRolster 10y ago
Indeed, Microsoft's lack of commitment to APIs is what inspired Joel's famous essay: http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html IMHO .net has lost some stability with the recent packaging systems like NuGet and chocolatey; they don't really encourage stability.
DonnyV 10y ago
The problem is not C# or .NET. The issue is Entity framework. Either stop being scared of using SQL and use something like PetaPoco or stop trying to turn objects into records and use Mongodb and just store the damn objects.

r-s 10y ago

I have upgraded a very large Rails 3.2 app to 4.2 recently. It was about 2 weeks solid of work for my team. It was a project I inherited and when I got it the test suite took an hour to run. The biggest problem which I had was dealing with the dependencies. This project used just under 300 gems, many of them unmaintained and a few of them I had to fork to get to work with rails 3. I am very fast making things in Rails, for the most part I find it just works. When projects get to a certain size, very roughly around 50k loc, they become very slow to work on. Slow test suites and dependency hell become problems.

barrkel 10y ago
$ find -iname '*.rb' | xargs cat | wc -l 135106 No real problems working with this codebase. ~190 gem dependencies. Mind, most of the code is tests: $ find -iname '*.rb' | grep /spec/ | xargs cat | wc -l 96899

lmm 10y ago

The only library I've felt absolutely safe doing upgrades with is Wicket, because it makes extensive use of the type system to ensure that you only use it in supported ways: many classes are final, and even those that aren't have a lot of final methods. It can be frustrating to have to copy-paste a Wicket class when you want similar behaviour, but it works beautifully.

engineerDave 10y ago

The main problem I see in the ruby community, in this regard, is the willingness to make breaking changes and justify it via Semantic Versioning. While on the surface this seems ok the underlying problem, as I see it, is the old version isn't maintained, so essentially the only maintained version now has breaking API changes. There are few ways this could be addressed, e.g. separate branches for old gems, and some developers do actually do this but in the end I've noticed these legacy branches and gems just bitrot while the developer devotes their time to the new branch. So essentially to use the gem you have to make the SemVer API jump which then begins the dependency failure cascade dance you mention. I'm close to starting another new Rails job and I'm not looking forward to the inevitable rails rescue work on legacy codebases, yet this is the reality of a modern Rails developer. Also I think this upgrade work needs to be factored into "development time" and when you do I'm not convinced Rails is actually faster.

busterarm 10y ago
I think this is the source of the early focus on unit testing in the Ruby community. The problem is a lot of Ruby developers have not felt this pain yet and eschew testing because they work in startups that are in a state of permanent death-march. A little (okay, a lot) of unit testing goes a long way to ease this pain. The people making breaking changes in their gems usually/hopefully have good testing in place and the return output of their methods are documented.
- engineerDave 10y ago
  Fair points all. But the breaking changes I'm referring to are items like changing method names, most likely because OCD, and helper methods, etc. While good/great tests will catch this type of stuff in your code, it will still be a lot of chasing your tail refactoring code because someone didn't like the way something was named. I see this a lot in the ruby community. Its like some sort of crazy insanity that ruby devs exercise when changing publicly exposed API methods just because _____. smh
  - busterarm 10y ago

jetheredge 10y ago

I've felt like any project horribly out of date is a pain to get current, Rails is no exception to that. Sure, many Rails projects have a lot of dependencies, but so do other frameworks. Sure, part of your argument is static vs dynamic, but I'm not going to join you in that argument.<grin>

wwweston 10y ago

This is exactly the past problem I've had with every Rails app I've been involved with (none of them have been from scratch) -- even during the setup process there's an immediate reckoning with gem snarls and other version issues.