Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Sub-initiate needs help getting started

by barbie (Deacon)
on Aug 27, 2003 at 10:51 UTC ( #287000=note: print w/replies, xml ) Need Help??


in reply to Sub-initiate needs help getting started

There are several good suggestions here, but none that really highlight the testing on your development platform.

WAMP (Windows-Apache-MySQL-Perl) is just as capable as LAMP (Linux-Apache-MySQL-Perl) for development. Okay there are some Linux dependant features that you can't use, but in the main most of what you are likely to want is portable between Windows and Linux. Apache (1), MySQL (2) and Perl (3) are all available for the Windows platform and with a little effort can all work together.

(1) http://www.apache.org/
(2) http://www.mysql.com/
(3) http://www.activestate.com/

You didn't mention which database you were using, so if not MySQL you might not be as successful at finding a Windows version. Although if your existing database is accessible from your desktop, then you won't need to have a database on your desktop, unless you want it for the learning experience. DBI can connect to a database anywhere, as long as it has permission. If you don't currently have access to your database, it may only require a quick update to the permissions table in the database to let you in. Ask the company's Database Administrator if in doubt.

In the short term there is likely to be a steep learning curve in putting all this together, but in the long run you will have a good experience of figuring out how Apache config files work and getting Perl talking to a database.

Another poster mentioned having a Version Control System, which is a must just in case anything goes wrong. CVS (4) is available on Windows, which is good for basic projects.

(4) http://www.wincvs.org/

Once you've set everything up, the turn around for developing and testing can be much quicker. At my last company, I managed to get the designers, graphics bods and developers all using the same CVS repository and database, but with their own copies of the websites and web servers. They were then able to run the scripts and see the results for themselves before commiting to CVS and then testing on the test server. The subsequent projects were quite often finished upto 50% quicker.

Debugging a CGI script can be painful. However, if you are using Apache then the error logs can be a godsend. However, a quicker error report can be obtained via the use of:

    use CGI::Carp qw(fatalsToBrowser);
Place the above in your CGI script, and any fatal errors will get sent straight to the browser. Though ensure it's remove or commented out for production code.

If you want to use your own trace logs, without interfering with the web server log files, have a look at Log::LogLite. A straightforward mechanism for recording processing information, with the added ability to decide the priority of a message, thus enabling you to filter what message to trace without having to rewrite huge chunks of your code.

Alternatively, is it possible run portions of the script stand alone? If so then test scripts, like the ones found in many CPAN distributions may be a guide to help you. Test::MockObject is a great help if you want to test code without having a connected CGI or DBI interface.

Several posts have mentioned templating. If all the HTML appears in your code, whether via straight prints or using 'Here Documents', then this can create all sorts of problems. It maybe too overwhelming to transpose these into a templating system now, but it is definitely something to think about. There are several good templating modules/systems recommended here and it would be a good idea to have a look through them to see what suits you best. By having a templating system you may have found that much of the code to create each report is actually duplication of effort. Thus a new report can be as simple as writing a new subroutine that extracts the data and stores it in a format ready for the presentation process, then creating a new template to present the data. Quite possibly a half a day job or less for each report. And what happens when your boss decides it has to be in XML format or any other format in the future? Templating allows you to change the presentation layout without any changes to the data extraction and preparation.

Learning HTML and JavaScript isn't too demanding and there are many books and online resources which you may have found already.

However, I would concur with others that JavaScript is not something you should be too eager to rely on. There are many aspects of JavaScript that are useful, such as the form validation aspects, but anything that comes from the outside world should still be validated server side too. 'Taint' is the keyword here. Node 80037 might be of interest.

From your subsequent post I suspect you're on the right track already and may have found your job of producing the new report a little easier than you first thought. There is much food for thought here, so I hope it doesn't overwhelm you. Good luck and welcome to the community.

--
Barbie | Birmingham Perl Mongers | http://birmingham.pm.org/

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://287000]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2018-06-24 04:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?



    Results (126 votes). Check out past polls.

    Notices?