Previous | Table of Contents | Next |
Your Next StepsAfter reading though the first two-thirds of this book, you should have an understanding of the basics of Perl. You have by no means learned the whole language. On my bookshelf are at least half a dozen books on the Perl language with—discounting overlapping subjects—2,300 pages, and still some topics in Perl are not included. A single resource can't cover all of Perl; however, the following sections provide recommendations for your next few steps. The resources outlined here are presented roughly in the order in which you should seek them out. There are exceptions, but for the most part, following this order will solve your problems in the quickest manner possible. Your First StepWhen you have a Perl problem, trying to figure out what to do first is tough. You're frustrated, and if you've been working on the problem for a while, you're probably upset. Take a deep breath, don't panic, and convince yourself that everything will be all right. Believe it or not, this is an important first step. Most people will become blocked on a problem after a while, and all the frustration from being blocked will prevent clear thinking, so you might wind up making things worse. Walk away, get something to drink, calm down, and relax. You will solve this problem. Your Most Useful ToolThe most useful tool in your Perl toolbox is Perl itself. First, you need to determine what kind of problem you have. Usually, problems fall into two categories: faulty syntax or bad and incomplete logic. If you have a problem with syntax, you can usually break it down into two smaller problems: Either you're using some bit of Perl incorrectly, or you've made a typo. Run your program and examine the error message; it usually indicates Perl's best guess as to which line is wrong. Look at the line for any of the following:
If your Perl program runs but simply doesn't produce the right results, you probably have a problem in your logic. Before you go tearing things apart, follow these steps:
Many apparent logic problems turn out to be simple mistakes that -w and use strict will catch. Use them, and if you still have problems, read on. Debug Your ProgramIf you're certain that the syntax of your program is right, but it's just not doing the right thing, it's time for some elementary debugging. The first, and probably most used, technique in debugging a program is to use the lowly print statement. Used carefully in your programs, it can provide some runtime diagnostics as to what's going on. Look how print operates in this example: sub foo { my($a1, $a2)=@_; # Diagnostic added to see if everything's OK. print STDERR "DEBUG: Made it to foo with $a1 $a2\n" } Just remember that when your program is complete, you need to take out all the debugging print statements. I recommend putting some kind of string in them ("DEBUG") so that you can find them all later. Also, by printing to the STDERR filehandle, you can separate your normal output from the diagnostics. If you include the literal symbols __LINE__ and __FILE__ in your diagnostic message, Perl will print the name of the current line and file. The other approach you should try is to use the Perl debugger. You can use the debugger on almost any Perl program. Watching your program run step-by-step can be very enlightening. Instructions for using the Perl debugger are found in Hour 12, "Using Perl's Command-Line Tools." First, Help YourselfIf your syntax is all right and your logic seems to be okay, but you're just not getting the results you want, it might be time to seek outside help. The first place you should look for answers is in the Perl documentation. As indicated in Hour 1, "Getting Started with Perl," every Perl installation comes with a full set of documentation. For the 5.8 release, more than 2,200 pages of documentation are included with the distribution. Every module, every function, and most aspects of the Perl language are covered in this documentation, as well as a large Frequently Asked Questions list and tutorials. To get a list of the available documentation, type perldoc perl at a command prompt. Each of the manual sections is listed, as well as a general description of Perl. The Frequently Asked Questions list contains a list of the most commonly asked questions that beginners—and experts—have about the Perl language. It's worth browsing at least once, to get an idea of what kinds of questions are there, even if you don't completely understand the answers yet. If, for some reason, you do not have the Perl documentation installed on your system or perldoc does not present the documentation, you should first talk to your system's administrator to find the documentation. Having the documentation correctly installed is important because the online documentation matches the version of Perl you're running. Any other documentation might have differences. If you cannot access the online documentation, you also can find the documentation at http://www.perl.com. Learn from the Mistakes of OthersUsenet is a distributed messaging system that was developed in the early 1980s and spread to the fledgling Internet. Usenet is divided into tens of thousands of discussion groups, with topics ranging from meditation, gardening, computing, and science fiction to hockey and inline skating, along with regional groups for every region of the world. A few newsgroups are specific to Perl:
To read Usenet news, you need a newsreader, and newsreaders are not hard to find. You can go to any software download site and grab a newsreader. You can also go to Web Archives such as groups.google.com that mirror the Usenet newsgroups in a Web format and require only that you have a Web browser to read news. In these newsgroups, people post questions about problems that they're having with Perl, and other people answer the questions—all on a voluntary basis. Also, discussions about general-interest topics related to Perl take place here. An observation that has held true through my entire programming career is as follows: There are no original problems in computing. Any problem that you are having, someone else has had before. The trick is finding who asked the question and what answer that person found. It's very likely that at least one person has asked a remarkably similar question to yours in one of these newsgroups. Google maintains an online history for much of Usenet. Using its search engine, with a few well-chosen keywords, you'll likely find the answers to your question. For example, say that you want to know how to write a Perl program to fetch a Web page. Go to groups.google.com's Advanced Search screen, and fill in the screen with the following: Keywords: fetch web page Group: comp.lang.perl.misc For this example, leave all the other fields blank. When the search returns—with thousands of matches—most of the matches will have to do with the topic you asked about. You should remember a few points about the articles that you read in Usenet:
When All Else Fails, AskIf you've checked the online documentation, your books, and Usenet history, and you still don't have an answer to your question, you might need to ask someone. Asking for help should be your last resort, certainly not your first. Experts are a unique medium for answering questions. They can take your badly phrased question and sometimes come up with a genuinely good solution to your problem. However, unlike the other resources previously mentioned, people do not have an unlimited capacity for answering questions. They will get tired, they will have bad days, and they will especially get tired of answering the same questions over and over. Although it's very likely that the person you're asking may know the answer, remember that you're borrowing that person's time and experience to get the answer to your question. It's your responsibility to do a reasonable amount of searching before asking someone else. To ask a question in Usenet, you need to use a newsreader or one of the previously mentioned Web interfaces to Usenet News. As you're assembling your question, follow these guidelines:
After you post your article to the newsgroup, wait. Usenet news can take a few days to propagate to the entire world, and people don't always keep up and read every article. Be patient, and go on to the next problem while you wait. Whatever you do, do not post to Usenet again with your question too soon. Wait at least a couple of weeks before asking again. Rephrase your question, make sure your subject line is clear, and then try again. The responses to your article can start immediately (within a few minutes) or could show up a month or more after you posted. As I said before, the quality of the responses will vary greatly. Some will be informative, and others will be wrong. Some respondents will be gracious and polite, and others will be exceedingly rude. It's considered good Netiquette to thank the responders and ignore any flames you've received. Another Place to Look and Ask: PerlMonksThe PerlMonks web site (www.perlmonks.org) is another useful resource for Perl programmers. It's a fairly easy-to-navigate web message-board system that provides answers to Perl questions and discussion of Perl-related topics. Between 25 and 40 questions are answered daily in the "Seekers of Perl Wisdom" portion of the site and most questions are answered within 24 hours. A wide range of people seek help at PerlMonks, from those just starting out with Perl to knowledgeable users who are looking for opinions on modules or articles before publication. Like Usenet, those answering questions are all volunteers and have diverse backgrounds and experiences with Perl. As with any free resource, the quality and depth of answers can vary from response to response and from day to day. In addition to the guidelines mentioned for Usenet, Tim Vroom who runs PerlMonks recommends a few more suggestions:
I've used this resource myself a few times to ask questions, and visited to answer questions on occasion, and I recommend it highly. |
Previous | Table of Contents | Next |