Sherlock Holmes and the Case of the Broken CGI Script
This month, I'd like to address the general question, "I downloaded
a script and it won't work." that I get about 5 or 6 times every day.
However, the way that I will answer the question, is by telling
you a story. I am going to tell you a story about me. A mystery.
It is a story about how I debug scripts on the zillions of different,
intractable, curmudgeonous systems that exist on the web when I have tried
all the common debugging practices.
It is a story about how I find the culprit bug when I am not exactly sure
about how the operating system works, which web browsers are trying to run
the script, what funky directives the local system administrator has
applied to the server, or any other number of big, hairy, ugly question
marks that stand between me and a programming-free weekend.
It is a mystery which, as most mysteries do, begins with Sir Arthur Conan
Doyle.
Let's see what Doyle has to say about debugging.
"By a man's finger-nails, by his coat-sleeve, by his
boots, by his trouser-knees, by the callosities of his forefinger and
thumb, by his expression, by his shirt- cuffs -- by each of these things a
man's calling is plainly revealed. That all united should fail to
enlighten the competent inquirer in any case is almost inconceivable."
- From A Study In Scarlet
Well, this may not seem like a discussion of software debugging, but it
really is. What Doyle is trying to say is that all software and hardware
bugs WANT to be caught. In fact they want to be caught so badly, that
they carefully lay clues for you as to their whereabouts. Perhaps Doyle
meant to say something like the following:
"By a scripts error message on the command line, its
output to STDOUT, by the HTTP message it sends to the web browser window,
by its entry in the error log, by the interaction of its algorithms, by
the libraries it calls and the responses sent by them, -- by each of these
things a scripts failures are plainly revealed. That all united should
fail to enlighten the competent hacker in any case is almost
inconceivable."
- From A Study In CGI
As a debugger, it's your job to listen to those clues, put them together
into a theory which can be tested, and test the theory against the
software package. In every case, you will bat yourself on the brow
and say to yourself, "Doh! Of course, how simple!". Because, when all is
said and done, computers are pretty simple creatures and when they break
there are pretty simple reasons.
The Virtue of Nothingness
Benjamin Hoff once revealed this interesting little story about Taoism and
I suppose I might pass it along to you.
"I am learning," Yen Hui said.
"How?" the Master asked.
"I forgot the rules of Righteousness and the levels of Benevolence," he
replied.
"Good, but could be better," the Master said.
A few days later, Yen Hui remarked, "I am making progress."
"How?" the Master asked.
"I forgot the Rituals and the Music," he answered.
"Better, but not perfect," the Master said.
Some time later, Yen Hui told the master, "Now I sit down and forgot
everything."
The Master looked up, startled, "What do you mean, you forgot
everything?" he quickly asked.
"I forgot my body and senses, and leave all appearance and information
behind," answered Yen Hui. "In the middle of Nothing, I join the source
of All Things."
The Master bowed. "You have transcended the limitations of time and
knowledge. I am far behind you. You have found the Way!"
Benjamin, added, "An empty sort of mind is valuable for finding Perls and
Tails and things because it can see what's in front of it. An Overstuffed
mind is unable to." (Well he actually spelled it like "Pearls", but we know
what he meant!)
What does this have to do with CGI debugging you ask? Well, it has
everything to do with CGI debugging. CGI debugging is not a skill. It is
not a thing you learn in school. It is not something that is particularly
aided by FAQS, or books, or system administrators, or discussion boards.
CGI debugging is a state of mind.
If I have spent more than an hour on a problem I stop. Very few problems
necessitate more than an hour to solve, so if I've been sitting there for
an hour I can be sure that it is most likely that the problem I am having
is not the bug, but me.
At this point, I turn off the monitor, light a candle and some incense,
(which I always have a store of in my middle desk drawer) turn on some
music, and lie on the floor and try to isolate instruments in the songs into
their separate tracks.
Note: For debugging I recommend "Technotronic: The Best of
Trance", anything by the Cocteau Twins or Enya, "Wish You Were Here" from
Pink Floyd or "Kiss" from the Cure.)
I might even go out and walk around the block if
it is warm and sunny...there happens to be a good climbing tree outside my
work.
About 20 minutes later I should be ready to get back to work having
achieved several crucial things.
- I am not one script closer to a heart attack at 35.
- I am not angry or frustrated.
- I have cleared my mind of all my preconceived ideas about what I
think the bug is saying and am prepared to "listen" to the bug to
find out what it says it has to say.
- I am not intimidated by the script. Programming is like riding
horses. The minute the script thinks that it is in charge is the
minute it throws you off. (Well, most horses are not that mean, but
you know the expression)
Newtonian Methodology and the Nitty Gritty of Debugging
- Newtonian Methodology and the Nitty Gritty of Debugging
- Figuring out Where you are
- Advanced Error Hunting
- In Conclusion
|
eBook library