http://www.perlmonks.org?node_id=44937

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re (tilly) 1: bulletin board
by tilly (Archbishop) on Dec 05, 2000 at 08:44 UTC
    If you want good answers, you might wish to take the advice offered here.

    Aside from that, at a glance, you don't use strict, you are using cgi-lib.pl rather than CGI, your temp file handling has a ton of race conditions, your lock file handling means that if anything went wrong it would tend to randomly fall over.

    I don't know what specifically causes the (unspecified) symptoms that lead you to post, nor do I feel inclined to dig into it deeply enough to figure that out...

Re: bulletin board
by extremely (Priest) on Dec 05, 2000 at 08:36 UTC
    What doesn't it do? What does it do instead? Are there any errors you can report from the error log? What does the user see? Have you tried running the script from the command line (setting env variables you need first)? What was the result of that? Did you write this script yourself or "borrow" it? Have you tried "perl -cw script.pl" from the commandline to ensure that the script compiles correctly and without warnings?

    Oh yeah, "use strict;" and "use CGI;" and so on and so forth. "#!/usr/bin/perl -w" and

    --
    $you = new YOU;
    honk() if $you->love(perl)

Re: bulletin board
by repson (Chaplain) on Dec 05, 2000 at 09:33 UTC
    This program does seem to have a few problems in the general design area (I have not looked at every line of code).
    Heres a few points to look into.
    • this is one of the tasks I used to learn perl :). Since then I have made more advanced versions using relational databases and message threads, it is something you can rewrite again and again as learning progresses.
    • warnings and strict save lots of time in debugging and sanity.
    • cgi-lib.pl is out of date, use CGI.pm or if you can't maybe CGI_Lite.pm
    • why do you use a seperate subroutines.pl?
    • why do you have four subs (box1,box2,box3,box4) which seem to repeat most of the functionality of each other. Maybe have one sub and pass it an argument for box number and have interpolation and a few if statements to handle any differences between the boxes.
    • your language regex's could be joined and should ignore case ie $in{Comments} =~ /dang|damn|bloody|darn/i
    • maybe you could have a common error reporting sub instead of pasting it everywhere you need it
    • databases - even DBD::CSV - are good :)
    • for a full discussion on a working (but not too complex) bulletin board look at merlyn's column.
    • try, try again
    • if you have any specific problems, please clarify
Re: bulletin board
by turnstep (Parson) on Dec 05, 2000 at 23:00 UTC

    As the others have said, the code above has many problems. If you just want a good working bulletin board, you should probably look for one of the many that others have already written. If you are doing it for a learning experience, try to post smaller portions of code and ask about a specific problem instead of posting the entire code and asking for "any problems."

    In general, writing a good bulletin board is a tricky thing, and can be much harder than it looks. I've written my own and it's now at 4000 lines (and growing), and I tend to write small, efficient code. :) Here are some things to keep in mind when rolling your own:

    • Use a database if possible. It saves a lot of trouble.
    • If you can't use a database, keep the data separate from the html files that are displayed. Keep the html out of your code as much as possible. Break up the data into multiple files, and create your own indexes (subsets of your data) to allow quick accessing of the data.
    • Check and double-check your file locking. This part will really get you in trouble: since multiple processes are writing to the same file, a simple mistake can cause your files to be erased.
    • Some sort of login/authentication will be needed eventually. Design it that way from the beginning.
    • Abstract everything as much as possible. Adding or removing an entire table, for example, should involve changing a configuration file and NOT the code. Things such as the error messages, the names of the boards/threads, the "improper language" words, etc. should not be inside the main code itself.
    • Perlmonks is a great resource, especially for specific problems in large projects. :)