Recently in Code craft Category

Run PHP tests in your Perl test suite

By Andy Lester on August 17, 2010 5:30 PM | 5 Comments

Sometimes you've got a big codebase that isn't just Perl. Maybe you've got PHP mixed in with it, and you want to test the PHP along with all the Perl code, too. Perl's prove program doesn't care if the testing results it parses are from Perl, PHP or even static files, so long as they're in the TAP format. However, actually getting prove to run those PHP programs takes a little doing. Fortunately, Test::Harness 3.xx has hooks for source handlers.

David Wheeler has written about running PostgreSQL tests under prove in his blog and I stole from his code shamelessly to create TAP::Parser::SourceHandler::PHP, released to the CPAN this morning.

So now, to run the Perl .t files and the PHP .phpt files all in one swell foop, here's what we do at work:

prove -r \
    -I/home/alester/proj/Lib \
    --source=Perl --ext=.t \
    --source=PHP \
    --ext=.phpt \
    --php-option=include_path=/home/alester/proj/Class \
    --php-option=extension=.phpt

That --source=PHP tells prove to load up TAP::Parser::SourceHandler::PHP. The --php-option tells prove to pass those options through to the SourceHandler. If we had PostgreSQL tests or MySQL tests, we could use the SourceHandlers for those that David Wheeler has written as well.

Now we can test everything all in one run, and we get all the benefits of Test::Harness 3.xx, like parallel tests and TAP archiving and so on.

To InformationWeek re: static code analysis

By Andy Lester on May 4, 2010 12:32 PM | 1 Comment

Sent to editor of DrDobbs/InformationWeek

I enjoy Sid Sidner's article on static code analysis tools, but was surprised to see two big omissions, especially as they may provide a low-cost point of entry to the organization just starting to look at static analysis.

First, PC-Lint is a relatively low-cost tool that does a fine job of C/C++ analysis. It's been around for years, and has found many C bugs in my code back in the early 90s. I've also been using the open source Splint, for years on the Perl 5 and Parrot open source projects. Although Splint's not nearly as complete a package as Coverity's Scan product (Coverity runs Scan on dozens of open source projects for free as a service to the community), it's a great introduction to the power of static code analysis tools. I also suggest readers check the "List of tools for static code analysis" page on Wikipedia.

Second, one crucial point missed is how any tool is going to require tuning. Splint will generate hundreds of errors in each source file on its first run on your code, since nobody in the real world is as pedantic as the tool is. Each organization will have to decide which policies are worth following, and which are just noise.

Finally, static code analysis isn't strictly for C++ and Java. Many dynamic languages have similar tools. For example, Perl::Critic is a fantastic tool for analysis of Perl code, as well as an extensible framework that lets each organization create custom policies to fit its own development practices.

Perlbuzz news roundup for 2010-04-22

By Andy Lester on April 22, 2010 10:29 AM | No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Perlbuzz news roundup for 2010-04-05

By Andy Lester on April 5, 2010 10:10 PM | No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Perlbuzz news roundup for 2010-03-09

By Andy Lester on March 9, 2010 10:46 AM | No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Help keep the world safe from SQL injection

By Andy Lester on February 6, 2010 2:42 PM | 3 Comments

A while back, I put up bobby-tables.com as a repository for showing people the right way to handle external data in their SQL calls. Whenever someone pops up on a mailing list or IRC and they're building SQL statements using external tainted data, you can just refer them to the site.

In the past few days, I've spiffed up the site (with design help from Jeana Clark) and added pages on Perl and PHP. I need more examples, though. It's 2010, and there's no reason anyone shouldn't know about parameterized SQL calls.

The site source is hosted on github, so if you have any contributions, please fork it and let me know about your applied changes, or you can email me directly.

Thanks!

P.S. In the next few days, I hope to fire up some redesign on perl101.org, too.

Perlbuzz news roundup for 2009-12-22

By Andy Lester on December 22, 2009 1:42 PM | No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Perlbuzz news roundup for 2009-12-08

By Andy Lester on December 8, 2009 12:53 PM | No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Perlbuzz news roundup for 2009-11-17

By Andy Lester on November 17, 2009 2:34 PM | 1 Comment

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

  • Pod::Simple 3.09 hits the CPAN (justatheory.com)
  • Strawberry Perl and the nightmare of installing Padre (use.perl.org)
  • A busy month for masak in Perl 6 (use.perl.org)
  • A productive week in Rakudo-land (use.perl.org)
  • Perl one-liners explained part III: Calculations (catonmat.net)
  • Handy one-liner to lowercase all filenames in a directory: ls | perl -lne'$x=lc;print qq{mv $_ $x}' | sh -x
  • Use CPAN's toolchain to improve your code (use.perl.org)
  • Future Perl snuck up on me (headrattle.blogspot.com)
  • Find the stupid bug in my progress indicator: say "$n so far" if ( $n % 100000 )";
  • I maeked u a shell: lolshell, written in Perl 6 (theintersect.org)
  • The horrible bug your command line Perl program probably has (perlbuzz.com)
  • Frozen Perl 2010 looking for speakers (news.perlfoundation.org)
  • apache2rest is a new framework for REST APIs under mod_perl2 (code.google.com)
  • Putting MySQL on a ramdisk to speed up tests (use.perl.org)
  • Generating Feedburner graphs (catonmat.net)

The horrible bug your command line Perl program probably has

By Andy Lester on November 9, 2009 9:10 AM | 4 Comments

Most programmers know you have to check return values from system
functions. Unless you're just starting out as a programmer, you
know that this is bad:

open( my $fh, '<', 'something.txt' );
while ( my $line = <$fh> ) {
    # do something with the input
}

If that open fails the program continues on. The call to
readline will fail, return undef as if we're at
the end of the file, and the user will be none the wiser. If you
have use warnings on, you'll get a "readline() on closed
filehandle", but that's not much help when you should be dying.

Instead, you should be opening your file like this:

my $filename = 'something.txt';
open( my $fh, '<', $filename ) or die "Can't open $filename: $!";

This way, your user gets a useful error message if something goes
wrong, but more importantly, the program doesn't continue as if
nothing is wrong, potentially doing what it should not.

GetOptions needs checking, too

Unfortunately, I see programs where otherwise-sensible programmers
ignore the return code of GetOptions.

use Getopt::Long;
GetOptions(
    'n=i' => \my $count,
);
# Do something that uses $count
print "Processing complete!\n";

There are any number of ways the user can call this program incorrectly:

$ perl foo -n
Option n requires an argument
Processing complete!

$ perl foo -n=five
Value "five" invalid for option n (number expected)
Processing complete!

$ perl foo -m=12
Unknown option: m
Processing complete!

In all three of these cases, the user made a mistake, but the program
lets it slide without a mention. The user's going to be disappointed
with the results.

The solution is simple: Always check the results of GetOptions().
The easiest way is to task && exit(1) after the call:

use Getopt::Long;
GetOptions(
    'n=i' => \my $count,
) or exit(1);

It's simple, effective, and prevents unexpected sorrow.

« Business | Main Index | Archives | Community »