Development in The Enterprise
Unfortunately, I’m not talking about the USS Enterprise here (wonder in which language they coded Data. Does he run linux?), but about the corporate world. Having worked at different large sized companies, I usually associate working in The Enterprise to several aspects (limiting myself to those closely related to software development. For the others, please refer to more specialized sources):
- Multi project: A rather large IT department hosts dozens or hundreds of projects
- Complex interaction: Those projects are of course not independent. They are more or less closely related, most of them are actually modules of a larger application
- Multi level dependencies: Progressively, some parts were extracted as components, probably more than once, so the dependency list is multi level (A → B → C). If you are a bit unlucky, it is more a directed graph than a tree.
This means that the first thing you need to achieve to be able to be productive on your small piece is some kind of isolation. Keep this in mind while I go back to Ruby.
Ruby open door policy is quite explicit in the Open Classes feature (for the non-natives: Ruby classes can be reopened and modified at any time, even those of the standard library. I can add a method to String if I want, I can even modify FixNum [which is the class of the ‘1’ literal] to have all number’s output in latin numerals).
The developer’s Holy Hammer
To the first time visitor (as we all were, one day), this looks like a developer Holy Hammer: a simple and elegant solution to a lot of different problems from providing more fluent interfaces to existing classes (what is not to love in ActiveSupport work on FixNum allowing expressions like 2.days.ago ?) to allowing for quick patches of bugs in any library (sometime, you just cannot wait for the next version).
Of course, those situations have solutions in other languages (you can modify and recompile a C library, you can even update a class inside a java jar), they are more hacks than built-in functions - it has never be so easy.
The integrator nightmare
But as an integrator, it’s something that keeps you awake at night: anyone “upstream” of you (ie, working on a project you depends on) can decide on a whim to alter any method behavior, without any real way to know it, until it is too late. It effectively destroys isolation, as not part of your system can be changed by anyone. The code you produce yourself for “downstream” projects can be modified also, making the support an heroic task. Worst even, two different teams can have the same smart idea of overriding some method on “Array”, letting the build process decide which one will win.
Quite unsurprisingly, the Rails framework is a big user of the Open Classes feature, notably in ActiveSupport.
Again, Ruby is not the only nightmare candidate here (I’ll let you imagine the consequence of my subtly modified jars in your enterprise application), and the openess (and consequence of) of the language is debated inside the community, but it is so easy to do that it will happen, and quite difficult to stop even with the amount of procedure weaponry that you can expect in a corporate world.
Refinements to the rescue
Refinements are a nice solution to this problem that keep the developer’s power without terrorizing the integrator by simply allowing those kind of “monkey patch” to be limited in scope (for example inside a single module). It ensures you that your little pearl of coding will not have any impact outside of a well walled garden, and that any coding brightness from the upstream teams will not break your functionalities.
Now, from the technicalities, back to what they (and more generally Ruby and Rails) means in the context of the Enterprise
Ruby, Rails and the Enterprise
“The problem with Rails today is that 1/2 the people are afraid Rails is turning into Java and the other 1/2 are trying to turn it into Java”
I’m not saying Ruby and Rails need to be Enterprise-usable (I think they should, but this is a personal opinion), certainly not that this should be the first priority, but disrespecting any opinion on this subject (mine, yours, others), Ruby and Rails actually have gone a long way toward being usable in the enterprise, without losing so much of their appeal.
To support this, one could point to the number of libraries than now exist to tackle almost any problem, from parsing to manipulating git objects to graph databases, often combining Ruby beautiful terseness with C or Java back-ends (why rewrite everything when it is not needed?).
Or, enlarging the scope to encompass the whole development lifecycle instead of just the code, to the build and packaging options like Rubygems (do you remember how life was in the Ruby world before Rubygems?) or Bundler (same question). And how deployment of Rails (and others) applications changed with Capistrano and how managing rubies became as simple as “rvm install 1.9.2”?
Rails is certainly no more a “small and simple framework”, but this is not due to some sort of corporate assimilation, it is just the price of maturity. Rails 3.0 has been a boon for plugin developers, making the ecosystem explode with plugins going from managing your security to simplifying forms to beautifying your application.
I think features like Refinements, beyond their intrinsic benefits to the language are are a good step toward improving Ruby’s appeal to both worlds, which is something I welcome.
And, by the way, never forget that the language that unleashed Websphere and EJBs on a largely unsuspecting world was initially designed to run inside your TV box.