Very interesting. This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me.<p>But this is more advice in the style of an STD prevention campaign. "You aren't just sleeping with that gem, you're sleeping with every gem that gem ever slept with." Which, admittedly the blog author isn't taking quite to abstinence advocacy levels, but also rings kind of true.<p>Reimplementing basic stuff across projects probably also keeps up your programming chops. The practice would help make the trivial stuff truly trivial for you.<p>But what worries me about this advice is that there are some things that feel like they're trivial to implement but actually have quite a few subtleties and gotchas. In a language as dynamic as Ruby, you might even end up doing something awful (like letting your xml parser run arbitrary code). If the subtle bugs are located in gems, you only need to fix the gem to fix it all.<p>But then again, how often do you own the gem? Even it's open source and you can fork it, the whole point of a gem is encapsulation. You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them.<p>I don't feel like I have answers to these questions right now. Just worth thinking about.
We've been doing the same for the past year or so at Mogotest and the results have been great. To build on the points in the articles:<p>- Exceedingly few gems provide any semblance of a human-readable changelog and even fewer care about targeting multiple APIs at once. Assuming you don't just blindly update your entire Gemfile at once, you're going to end up spending much more time than is reasonable to determine whether you should upgrade that gem you just pulled in.<p>- There's a huge stigma against libraries ever being "done." So, they keep adding new features or coming up with better APIs. You're going to end up having to go along for the ride.<p>- Rails doesn't have much of an API per se or at least not one that's likely to survive a major upgrade in tact. After the Rails 2.3 -> 3.0 upgrade, we just flat out avoid anything that's a "rails plugin." I suspect our 3.2 -> 4.0 upgrade will go much smoother this time around.<p>- If you target multiple rubies, it becomes much, much easier with a slimmer dependency graph.<p>At the end of the day, a lot of this is just the general debate of building it vs using a library that any language or environment has. But I think some of the cultural aspects of Ruby amplify the debate as it's just a much faster moving target, which may be at odds with stable apps.
For faster updates in the future, you may want to use this in your Gemfile for the coming weeks:<p>gem "rails", "~> 3.2.11"<p>See <a href="http://gembundler.com/v1.2/gemfile.html" rel="nofollow">http://gembundler.com/v1.2/gemfile.html</a> for the meaning of ~>.<p>Also, I think that "having a good test coverage" is quickly becoming more interesting that plainly "avoiding breaking stuff" or "adding new features faster": it's also being able to quickly answer to security threats, either via official gem updates and despite regressions (<a href="https://github.com/rails/rails/issues/8832" rel="nofollow">https://github.com/rails/rails/issues/8832</a>), or via quick work-arounds.
It's always good to use Vagrant (or any other method to be quickly able to refresh the dev environment) and routinely do destroy/up. This is for me so far the best precaution to keep the application light on dependencies.