Eric Schwartz wrote:

> 
> Here, your focus is on what your code is *doing*.  Think, instead,
> about what it *is*.  That is, what data are you collecting, and what
> are you doing with it?  I would argue that instead what you need is a
> Configuration object that stores data like, "What directories should I
> be fetching from which machines, and where should I put them?", and
> give that object methods like validate_directories() and so on.
>
> ...
> Then think of what other things you want to store data about.  Say,
> your machines.  You could define a Machine class that stored generic
> data, such as its name, location, and other generic info.  You then
> could subclass that into HP3000, ZOS_box, and so on.  Each of those
> would contain methods like get_file(), which would fetch a file from
> that machine to the local directory, and maybe reboot(), which would
> annoy everybody else using that machine. ;-)
> 
> ...
> I'm in a bit of a rush right now, but maybe someone else will explain
> how a method such as I proposed makes it easy to test using
> Test::Unit-- otherwise, I'll get back to you later and try and explain
> it.
> 
> -=Eric

Many thanks.  I have clue where to begin now.  I will try and redo this 
more or less along the lines you recommend and post the result back 
here.  Just to clarify one point, the HP3000 drops off the files onto 
the host that is running the Ruby script.  There is no service running 
on the HP3000 that will respond to a file transfer request, although, as 
you point out, that does not preclude a scenario where the drop machine 
is not the script runner.

Regards,
Jim

-- 
Posted via http://www.ruby-forum.com/.