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?
Standard out is ok for only certain tasks, particularly if there is
an extended time aspect to the problem.

> ... 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)
-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.)

If you are getting something as fundamental as somethign screwing up
your DB saves, I would probably start looking at whether you are
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
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
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.