From: Hugh Sasse <hgs@...>
Date: 2006-10-13T00:35:59+09:00
Subject: Re: Debugging in the large, modern practice?

I've delayed replying for a bit because lots of good stuff is
coming in, and I didn't want to stem the flow or divert it, ...

On Thu, 12 Oct 2006, Richard Conroy wrote:

> On 10/12/06, Hugh Sasse <hgs@dmu.ac.uk> wrote:
> > I have a large application (which is actually a Rails app) which is
> > behaving oddly (I can change items in a DB twice, but 4 times
> > fails), and using all the conventional approaches I have learned for
> > debugging (printing things out, logging to files, ...)
> 
> I am not being pedantic here, but have you not tried a debugger?

I'm not yet clear where to set the breakpoints, and so on, because
I don't understand enough about the nature of the failure.  But
I probably need to re-examine the Ruby debugger, because my knowledge
of it's capabilities is somewhat limited....   So, up to now, no,
I have avoided this approach.

> Standard out is ok for only certain tasks, particularly if there is
> an extended time aspect to the problem.

Hence the logging...
> 
> > ... what are the parallel developments in debugging large
> > systems?  By large, I mean sufficiently large to cause problems in
> > the mental modelling of the dynamic nature of the process, and
> > involving considerable quantities of other people's code.
> 
> -Remote debugging (ie. servet, web service, .NET debugging in your
> IDE as if it was a locally running program)

I'm not on .NET, I'm on Solaris and also Cygwin.  Now, some
people will want to spit molten sulphur at me for using Cygwin.
Given that I'm more fluent in Unix than Windows, I'd be glad of
an alternative if there is one, but I don't think that's the
problem here anyway.  Oh, and the usual vanishingly 
small budget constraints for us seem to apply.  "There might be
money next year"

> -Automated Unit Testing (JUnit, NUnit, RUnit)
> -Unit Test coverage measuring (rcov, JCoverage, Clover)
> -Automated UI testing (of web UIs, excellent examples being WATIR,
> Selenium etc.)

Using Watir already.  Other testing could do with improvment.
> 
> If you are getting something as fundamental as somethign screwing up
> your DB saves, I would probably start looking at whether you are

Well, the logs show the save! commands are getting called OK, with
the right values.  I've said I've no reason to suspect the database.
Leaving reason aside, my emotions tell me that maybe I should
suspect, having read rather uncomplimentary stuff about MySQL,
advocating PostgreSQL, but I don't know enough about the DB issues
to be sure.  This is my first serious DB project.  So for now I
suspect my own code.  So I'll need to refactor to improve testing.
 
> properly covered by your unit tests. If you find gaping holes in your
> test coverage I would write more tests to expose the problem.
> 
> > Given the prevalence of metaprogramming in Ruby, I'll phrase this
> > another way, as a meta-question: what are good questions to ask to
> > progress along the road of improving one's ability to debug large
> > systems?
> 
> Simple answer: break up large systems into smaller systems
> that can be tested independently (and possibly even replaceable). Its
> not so much a component concept as just the age old practice of
> modular systems.
> 
> I am not sure how this might apply to large Ruby apps, my gut feeling
> is there are not many huge ruby apps out there. The biggest I have
> heard is around 30000 LOC, which is an awful lot for Ruby. Equivalent

I don't think it's that big.

> functionality in a more conventional language (Java, C++, NET etc.)
> would be bigger.
> 
> Rails apps are a bit different though, as Rails is an opinionated framework,
> and logically dictates where your code should be. You also don't end up
> writing much Ruby code. If you are, you're probably not leaning on the

I'm sure my use of rails is less than optimal.  I still don't fully
undestand it.

> stack enough. My gut feeling is that code bloat in Rails will very quickly
> reveal itself that you are doing something wrong (possibly when test code
> starts to get difficult to write). To get 30000 LOC in a Rails app, when it
> is written well, your app would be huge, massively featured and have a
> pretty huge UI (lots of RHTML), it might be possible to achieve that if you
> are localising views a lot (while globalise nicely lets you avoid this as
> much as possible, things like date controls, right->left reading order,
> might make it easier to localise at the template level.

        Thank you.
        Hugh
> 
>