5 ms·

> Progress over stability > We have to dare occasionally break and change how things are to evolve and grow. > ...harder to swallow in practice. Especially wh

by Ologn 11y ago

> Progress over stability > We have to dare occasionally break and change how things are to evolve and grow. > ...harder to swallow in practice. Especially when it’s your application that breaks from a backwards-incompatible change in a major version of Rails. It’s at those times we need to remember this value, that we cherish progress over stability... I encountered this doctrine first hand. A division of a company I worked at had its division's website rewritten in RoR by some outside consultants. Even brand new, it was a mess of Ruby gems of conflicting dependencies which was undeployable. The build system was a train wreck as well. Some of the main web pages of their web sites like rubygems.org were not available - the web site had "progressed" and when you clicked on a link, the page explaining anything had disappeared. I mean hell, go to rubyforge.org this minute (1:15 PM EST) - it is down, of course. The blog of the author of the Ruby gem that then was the main gem that handled web serving did not inspire confidence. As I would have to maintain it (as a sysadmin, not programmer), I refused to deploy the system, since it was an unreproducable mess of conflicting gems and gem versions and kludges. They decided to pay the RoR consultants additional money, despite them having never delivered a working system. By the time I left, it still was never deployed. The division closed dozens of offices soon after, and then the division shut down - perhaps not completely related, but probably somewhat related to this project. Meanwhile, the company's other divisions had decent programmers programming for Java application servers, and that code and those servers were much more solid. Builds rolled out easily (and could easily be rolled back if need be). It was really night and day. It makes sense this contempt for stability is explicitly part of their doctrine.

FooBarWidget 11y ago
That sounds like a Rails app from the 2.x days (circa 2009). Back then, "a mess of conflicting dependencies" was a indeed problem. With the introduction of Bundler, that problem has been fixed ever since.
bdcravens 11y ago
DHH's is talking about the doctrine of the framework, not random apps built atop the framework. rubyforge.org has been offline for over a year and a half, as announced over 2 years ago. You describe a Rails application written by outside consultants that was undeployable, and compare it to apps written by internal Java developers. I believe the quality of the developers had more to do with the deployability than the languages of choice. You could just as easily have a Java application written by consultants, with undocumented JARs, magical PATHs, mystical server.xml's to make things work just right, and crazy ant scripts.
- Ologn 11y ago
  > rubyforge.org has been offline for over a year and a half, as announced over 2 years ago. To those not drinking the RoR kool aid, this is toward my point. Two years ago rubyforge.org was a central repository of Ruby gems. Now it is a web page that says "RubyForge Could Not Connect to Database:". Of course, in the minds of some, this does not reflect poorly on RoR but me - I am supposed to know that two years ago they decided to transform this central hub of Ruby gems to a web page that says "RubyForge Could Not Connect to Database:". This kind of thing is par for the course with Ruby. I know that the http://perl.org/cpan http://perl.org/cpan page I used twenty years ago is still redirecting somewhere sane, but rubyforge.org ? "RubyForge Could Not Connect to Database:" - and the fool is me for not knowing why. This is typical of the kind of thing you deal with in RoR world. Insofar as projects - a Java project can be junk just like an RoR project can, yes. The thing though is that relatively, the core Java infrastructure, community, API etc. has been much more stable over the past twenty years. Hearing that rubyforge.org disappeared eighteen months ago to be replaced by this cryptic message makes me more down on RoR-world than if it was just their website being down for a few hours. It's the kind of thing you deal with in RoR-world all the time.
  - steveklabnik 11y ago
    Rubyforge.org was a 'central repository of gems' in name only. The transition to gemcutter, which turned into today's rubygems, happened in 2009: http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html http://www.rubyinside.com/gemcutter-is-the-new-official-defa...

by Ologn 11y ago

FooBarWidget 11y ago

That sounds like a Rails app from the 2.x days (circa 2009). Back then, "a mess of conflicting dependencies" was a indeed problem. With the introduction of Bundler, that problem has been fixed ever since.

bdcravens 11y ago

DHH's is talking about the doctrine of the framework, not random apps built atop the framework. rubyforge.org has been offline for over a year and a half, as announced over 2 years ago. You describe a Rails application written by outside consultants that was undeployable, and compare it to apps written by internal Java developers. I believe the quality of the developers had more to do with the deployability than the languages of choice. You could just as easily have a Java application written by consultants, with undocumented JARs, magical PATHs, mystical server.xml's to make things work just right, and crazy ant scripts.

Ologn 11y ago
> rubyforge.org has been offline for over a year and a half, as announced over 2 years ago. To those not drinking the RoR kool aid, this is toward my point. Two years ago rubyforge.org was a central repository of Ruby gems. Now it is a web page that says "RubyForge Could Not Connect to Database:". Of course, in the minds of some, this does not reflect poorly on RoR but me - I am supposed to know that two years ago they decided to transform this central hub of Ruby gems to a web page that says "RubyForge Could Not Connect to Database:". This kind of thing is par for the course with Ruby. I know that the http://perl.org/cpan http://perl.org/cpan page I used twenty years ago is still redirecting somewhere sane, but rubyforge.org ? "RubyForge Could Not Connect to Database:" - and the fool is me for not knowing why. This is typical of the kind of thing you deal with in RoR world. Insofar as projects - a Java project can be junk just like an RoR project can, yes. The thing though is that relatively, the core Java infrastructure, community, API etc. has been much more stable over the past twenty years. Hearing that rubyforge.org disappeared eighteen months ago to be replaced by this cryptic message makes me more down on RoR-world than if it was just their website being down for a few hours. It's the kind of thing you deal with in RoR-world all the time.
- steveklabnik 11y ago
  Rubyforge.org was a 'central repository of gems' in name only. The transition to gemcutter, which turned into today's rubygems, happened in 2009: http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html http://www.rubyinside.com/gemcutter-is-the-new-official-defa...