A GDB-like Debugger for Perl – Devel::Trepan

Earlier today I saw an interesting talk at a meeting of the NY Perl Mongers in which Rocky Bernstein highlighted some of his recent work creating a GDB-like debugger for Perl.  While Perl does ship with its own integrated debugger, which can be invoked with the –d switch, the Devel::Trepan module demonstrated appears to have great potential for turning into a Perl debugger that could one day rival or even exceed the current Perl debugger.  The Trepan module borrows much of its command set from the GDB debugger, which many users who have migrated to Perl from C\C++ might find helpful.  Moreover, the debugger as demonstrated, while still a work in progress, already appears to be functional enough to begin to be evaluated as a serious possibility for use in debugging tasks. This is a module that I will definitely be taking a closer look at in the near future and one that I think would be worth it for other Perl programmers to take a look at as well.  More information on the module can be found at https://github.com/rocky/Perl-Devel-Trepan. 

Effectively Timeout Slow HTTP Requests with LWPx::ParanoidAgent

One of the potential pitfalls of writing spiders or any type of application that makes use of http requests is that a slow or intermittent connection to the destination server can make your application hang. While modules such LWP do have a timeout parameter, this parameter is implemented in a way that only works well for timeouts regarding non-responsive sites. Responsive, but very slow, sites will often cause LWP to keep the connection alive and result in your application hanging up for longer than you desire. One way to deal with this issue is to consider making use of the LWPx::ParanoidAgent module. The module is a derivative of LWP, but it does not base its timeouts on time since the last socket read, its timeout counter is initiated at the same time the request is made. Thus if you specify a 10 second timeout, 10 seconds is the maximum amount of time allotted for the completion of the request. This module is used almost identically to the LWP module. For example:

use LWPx::ParanoidAgent;

my $ua=LWPx::ParanoidAgent->new;

$ua->timeout(30); #in seconds

my $response=$ua->get('http://potentiallyslowsite.com');
my $result=$response->content;

Another interesting feature of this module, is that it allows you to specify whitelists and blacklists to give you control over what links the module will actually attempt connecting to.  While the near universality of LWP may often make it the better choice, the LWPx::ParanoidAgent module is worth keeping in mind for any project that may deal with http requests to sites with questionable network connectivity. 

Test and Debug Your Web Applications with Tamper Data

Most Perl programmers at some point in their career are involved in a project that includes a bit of Web development.  One of the Firefox plug-ins that I occasionally find useful for the debugging and testing of Web applications is the Tamper Data plug-in for Firefox.  In particular, from a debugging perspective it allows you to capture HTTP and HTTPS headers as well as POST parameters, which can allow you to verify the requests that are being sent to your Web application.  On the testing side, some basic security testing can be done as well, since it allows you to modify captured HTTP/HTTPS headers and POST parameters prior to transmission. While someone that is heavily involved in the security testing of Web applications, would likely be better served by more robust intercepting proxies (e.g. Burp Proxy, etc) it is a nice plug-in to use to introduce people to some of the basic techniques that can be used to test Web application security.  An example of a captured Facebook login request can be seen below.

 

Notice, how it shows the different POST parameters and their values?  Any one of these parameters in the request could then be modified and submitted to the site.  Once the “OK” button is clicked, the request will be forwarded to the Web application, including whatever modifications that you have made. 

Testing Your Tests?

This is an idea that I still consider in the “alpha” phase, and one that I have not yet even begun to code a proof of concept of, but it is an idea that I would be interested in some community feedback on.  Testing has always been an integral part of the culture of Perl and one of the great strengths of the Perl community.  At a NY Perl Mongers meeting in June I saw a preview of the YAPC talk by James Keenan on testing that I think provides a nice introduction to testing for any that are not familiar with Perl’s Test::* modules. Here is a link to the video of the YAPC talk if any are interested:  http://youtu.be/A31VhNeGaw0

What I have been thinking about a lot lately though, is “how do you test your tests?”  In other words, how you do you know if the tests that you put in place are truly adequate.  What I have been thinking of is building a Perl program that will create let’s say 10 variants of a program that each contain a random “mutation” of the original code.  For example, let’s say that it is a math program being developed and tested, at random points in the code a mathematical operator (e.g. +) can be changed to another random operator (e.g. -, *, %, etc). This process would be repeated 10X to create 10 variants of the code that each has one random operator changed. 

Each of these variants could then be run against the testing set.  If the variants result in testing failures in all cases, the tests probably provide sufficient coverage of the codes functionality.  If one or more of the variants pass all tests, it is an indication that the tests are not robust enough to adequately assess the proper functionality of the application. I’ll try to post some proof of concept code soon.  Thoughts?

A Review of the Book "Modern Perl"

I recently finished reading through a copy of Modern Perl by chromatic and think the book serves as an excellent Perl resource, albeit one that I would not recommend as book for a first time programmer.  The book Modern Perl, is one that I believe is much more suitable for readers with at least some basic programming experience and I think it will be of the most benefit to those that already work with Perl, but have not kept up with the latest developments in Perl.  Perl has changed quite a bit over the last 7-8 years, in ways that would pleasantly surprise those that have not been following the evolution of Perl.  I particularly liked the conciseness of the book and how much information it managed to cram into 181 pages, yet it is this same conciseness that I think may make the book challenging for a programming novice. 

For more experienced programmers the book offers a wonderful way to rapidly bring themselves up to speed on the more modern ways of approaching Perl programming.  Coverage of such modern practices ranges from mentioning small changes like using cpanminus as a way to install CPAN modules and the newer three argument syntax for opening files to coverage of some of the major changes in Perl, such as the development of Moose as a more modern approach to OOP.  I was especially pleased to see the chapters towards the end of the book, such as those on “Style and Efficacy”, “Managing Real Programs”, and “What to Avoid”.  These chapters make the book one that goes beyond just teaching how to program in Perl and turns it into one that stresses teaching the authoring of quality Perl code. 

I would recommend that anyone currently making use of Perl take the time to look through a copy of Modern Perl, particularly since the author gives you the option of downloading the book entirely for free. For more information about Modern Perl visit - http://www.onyxneon.com/books/modern_perl/index.html

Basic Error Handling in Perl

Anyone that has ever sat at a computer help desk quickly becomes aware of just how many issues a user can have with even the seemingly easiest and most user friendly software around.  Whether it is the user that “lost” his email because he clicked on one of the sort buttons and now can’t find today’s messages or the user who manages to crash a calculator-like program because he decides to type “two” instead of “2”, it becomes readily apparent that computer users will often do things that many developers would find unthinkable.  It is important that software developers learn this lesson early in their career.  Whether for malicious reasons or innocuous ones, your application will be abused by those that make use of it.  While some previous posts discussed the basics of input validation and some modules that could be used to perform input validation, these are not the only useful techniques to consider.   Error handling is also a useful technique for dealing with potentially problematic situations that could arise.  For example, perhaps your application requires access to a file on removable media for certain functions or connection to a certain network resource.  While an “or die” type statement alone could be used to deal with the situation, error handling may provide you with a way to allow your application to route around the error or to at least fail gracefully.  The basics of Perl error handling is the eval statement, which is used as follows:

#!usr/bin/perl

use strict;
use warnings;

my $x=5;
my $y=0;

eval {
    my $result=$x/$y;
    print "$result";
    1;
} or do {
    print "Error: $@\n";
};

The above code works because if the code in the eval block executes it will return true, otherwise it will return false, and cause the code contained in the do block to execute.  The above example, forces the do block to execute by intentionally dividing by zero. 

It is also notable that there are several Perl modules that are highly useful for error handling as well such as Exception::Class, Error, and TryCatch.  These modules will be looked at in more detail in a future installment.