Three engineers are riding along in a car when the car suddenly sputters and dies. They try to start the car again but it won’t start. The electrical engineer says, “Looks like an electrical problem, probably the starter or the battery.” The mechanical engineer says, “I think it’s a mechanical problem, probably something in the transmission.” The software engineer says, “Why don’t we close all the windows, get out, get back in and try it again?”
Computer troubleshooting is a bizarre skill. It’s equal parts experience, gut, willingness to futz things up and luck. In most situations doing the same thing twice and expecting different different results is the mark of idiocy, but with computers it is the norm.
On Friday I traded about 10 e-mails with an IT guy who was having trouble installing Tasks Pro™. I’ve put a good bit of effort into the install script to account for numerous errors and give meaningful error messages, but all of these are built on the assumption that the server is running properly. Sometimes it isn’t. There are a lot of benefits to programming in an interpreted language, but this isn’t one of them.
The first screen of the install script would come up just fine, but hitting the ‘Next’ button resulted in a blank screen. My hunch was that there might be a parse error in the database settings file from when the database info was entered. This file isn’t included on the first screen, but is on the second screen.
That wasn’t it - the IT guy ran the script through command line PHP to test the syntax and it passed.
php -l -f filename.php
I had them turn on errors so that we could see what was failing, but that didn’t make any difference (still a blank page). I was completely out of ideas. I offered to try to debug over FTP/SFTP, but that wasn’t a good option for this customer.
Just as I was replying that I didn’t know what else to suggest, the IT fellow e-mailed me to say that restarting Apache had magically fixed whatever was wrong. :rolleyes:
Popularity: 2% [?]
Andrew adds this Comment:
At least your at the coalface to sort it out.
I had a network issue that needed a Cisco engineer to certify to the comms company that our router wasn’t the problem of our network outage.
Not being an engineer I didn’t speak “routish” to convince them. Even though logic would say its not the issue.
October 18th, 2004 at 8:53 pm