I code a while. Then hit upload to fire off my work to the server. Then I request the appropriate page in my browser.

If there are any problems, I run this shell script (as root -- so it can write to the error log) on the server using the telnet client:

if [ "$#" -eq 1 ]; then
   lines=$1
else
   lines=50
fi
echo
echo
echo "----------printing $lines lines----------"
log_file="/usr/local/apache/logs/www.myserver.com-error_log"
tail -n$lines $log_file
echo "#####################################">>$log_file
date >> $log_file
echo "#####################################">>$log_file
[download]

The lines in the shell script that append to the log_file mark it and time/date stamp it each time I dump the tail. This way, I can easily see which error entries are new with the most recent page load attempt. Very handy.

The rhythm of this entire cycle has become second nature to me. There is a 2-5 second delay with each save. But I don't even notice that any more. And the differences in the environment between the server and my box are enough that there would be sure to be surprises if I tested first on my local machine. It's just not worth it.

Everybody's different but this works for me. HTH

Easy. Treat your CGI programs like you would build an app in lower-level languages like C - use a Makefile!

Basically, all you need to do is to create Makefile entries for:

• testing your program (locally) (target test)
• debugging your program (target debug)
• uploading your program to the Linux server and running an LWP script to test your program on the Linux server (target publish)

Then you just write your script, add it to the Makefile file entries, and say:

make test
[download]

If all is OK, you say:

make publish
[download]

Else you just say:

make debug
[download]

Ah, you are on Windows. Of course then you use "nmake" instead of "make".

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Try webdrive (www.webdrive.com), it allows you to map a drive letter to an FTP site, meaning you can edit files as if they were local. Saved me hours for sure.

With this approach, you get rid of most of the bugs before it leaves your development machine, testing on the test virtual server will check machine specifics (like module versions, file paths, etc.) without damaging the production system, which, if all goes to plan, is the next to get the script, which you can quickly do a sanity check on.

As you can see, I go for the paranoid approach :o)

--
RatArsed

The key to make it work for me was to arrange the scripts, templates and modules so that everything was under one root directory that I could upload via rsync. That way I didn't mistakenly upload some pieces and not others and loose time debugging that kind of problem.

If the site you are building is live, I'd suggest uploading to some kind of staging area, then cutting over to the live site after a quick test. Changing environments often reveals things that even diligent local testing won't find.