How will my application function tomorrow?

Please help me understand how I can depend on my application performing
in a certain way if the classes (e.g. in libraries like ActiveRecord) it
depends on can change at any time by someone redefining the methods ?

Disclaimer: I am a Delphi refugee. I am used to delivering complete
applications in a single, albeit large, executable. I had Web services
in a single EXE: just copy it, start it, and it grabbed a socket and
just ran; no dependancies, no linking, no changes. I could even compile
in the client-side of SQL databases for a full database application in
one, ummutable file. I’m still getting used to lots of little files .

One think that worried me when I worked on large Java applications is
that someone could drop a new .java file in the mix at any time (e.g.
after QA) and change the way the application worked.

I understand that one can seal a Ruby class, but must one subclass and
seal every single class (like ActionRecord), and then change one’s
application to the use the sub-classes, to insure that some future
installation won’t do something unexpected ? And part of the beauty of
Ruby is that one can enhance a class by changing its methods; I don’t
want to lose that, just control it.

If testing replaces the contractual confidence of application-specific
interfaces, how can one be sure that, once tested, the application will
not find a modified library upon deployment to production? Or after
deployment ?

Or does each application have their own library and deployment
re-creates that environment exactly ?

Thank you for helping me get my head into the Rails space.

Cheers

On 8/21/06, Richard C Haven [email protected] wrote:

Please help me understand how I can depend on my application performing
in a certain way if the classes (e.g. in libraries like ActiveRecord) it
depends on can change at any time by someone redefining the methods ?

That problem is common to all shared-library approaches, which are
found in Java, .NET, Rails and many other environments. Even in
Delphi, you will be relying on a number of external libraries, such as
most of the Windows .dlls, so it’s not such a big step from what you
have been doing so far.

Normally, when you move an applicaiton into production, you want to
deploy it with a known set of libraries. With Rails, you can freeze
the current rails version you are using for development (rake
rails:freeze:gems), which copies all rails libraries into the vendor
folder of the application.

If a change to a library breaks compatibility, there is usually a very
good reason for the change (e.g. a security fix). A comprehensive
suite of automated tests helps detect these kinds of breakages.

In practice, I have very very rarely seen this happen. Libraries are
almost always more stable (in terms of versions) than your application
and will generally have a longer shelf-life as well.

You definitely don’t want to think about “sealing” ruby libraries. By
the very nature of Ruby, there is a lot of code out there that
achieves amazing things by redefining or extending existing classes or
methods (e.g. the Enumerable mixin or the various acts_as_* plugins
for Rails).

Depending on how you deploy your app, you can either choose a hosting
environment that gives you control over the installed gems or - if you
are deploying a stand-alone application - you can have a look at the
various packaging methods (RubyScript2Exe and friends), which package
up the required libraries into a single file.

In summary, I really wouldn’t lose any sleep over it. I don’t think it
is as big an issue as you’d expect.

Max

On 8/21/06, Richard C Haven [email protected] wrote:

Please help me understand how I can depend on my application
performing
in a certain way if the classes (e.g. in libraries like
ActiveRecord) it
depends on can change at any time by someone redefining the methods ?

And that answer to that question is:

Test Driven Development


– Tom M.