| Subcribe via RSS

Perl Module Monday: Test::Formats

August 24th, 2009 | No Comments | Posted in CPAN, Perl, XML

I was on vacation most of last week, so this week’s installment of PMM is going to be both short and self-serving. For this week, I’m going to “cheat” and talk about one of my own modules: Test::Formats. (I promise to not make a regular habit of using this feature to promote my own projects.)

This is a pretty simple concept: Rather than using lengthy, confusing regular expressions to test the validity of generated XML documents, why not use the validation already built in to the parser itself? The module isn’t for use on snippets, but then those can usually be tested with much simpler, easier-to-read regexp’s.

The tests you would write with this module are tests of the XML your Perl generates, not necessarily the Perl itself. Alas, time constrains me from any useful examples, so I hope you’ll check out the module itself on CPAN. Next week will be better, I promise!

Tags: , ,

Perl Module Monday: IPC::Run3

August 17th, 2009 | No Comments | Posted in CPAN, Perl

For this week’s Module Monday, I’m looking at a recent discovery: IPC::Run3.

I came across this one while looking for best-practices tools to use when executing a sub-process and manipulating all of the file-handles, not just the input, or just the resulting output. I’m going to need this for an upcoming project, one that is needed at $DAY_JOB but for which I’ve been cleared to develop it as a CPAN module rather than an internal one.

What sets this module apart, in my consideration, is the ease with which it allows you to manipulate the input and capture the output. IPC::Open3 does very much the same sort of thing, and has the benefit of already being part of the core. But it uses only open file-handles as its currency, which leaves me doing much of the same open/write-or-read/close logic over and over. This module, in contrast, is very Perl-ish in how it regards each of the parameters for STDIN, STDOUT and STDERR. You can use file-handles, of course, but you can also pass the content for STDIN directly, save the results from the output streams directly, redirect them from/to /dev/null, etc.

Time and tuits permitting, I should have my new work on CPAN within the next 3-4 weeks. And when I do, IPC::Run3 will figure prominently in how it functions.

Tags: , ,

Inaugural Perl Module Monday: Test::XT

August 10th, 2009 | No Comments | Posted in CPAN, Perl

(This kicks off what I hope to be a regular, weekly series on my blog: focusing on a Perl module that’s unsung, or at least under-sung, and hopefully in doing do drawing some extra attention to a tool I feel can help other Perl developers.)

For my first “Perl Module Monday” post, I would like to introduce you to Adam Kennedy’s Test::XT. This module has been around for several months, but I only recently took the time to look at it, and see how I could utilize it.

When I first discovered the CPANTS effort, and the enormous amount of work its creators had put into it, I immediately set about improving my scoreboard. In CPAN circles, this was known as “gaming CPANTS”. And for good reason– a high score is an indicator of nothing more than the fact that your modules pass those particular metrics, none of which measure actual code quality. They only measure the quality of your distribution. I argued (which is almost too strong a word, as the discussion never really got that heated) that as more authors took the CPANTS guidelines to heart, the end result would be worthy in and of itself, a different sort of quality that stood on its own. Think of Ruby’s “gems”, and the perception of how effortless they are to install; many people have the (mistaken) impression that Perl modules are difficult, and that impression most likely came from one or two isolated incidents (whether personal or related anecdotally). And, at least in my case, it has led to better overall module development. I no longer release even the initial version of a module unless I’m pretty confident that it will meet at least the “required” metrics, if not the optional ones as well.

This dedication, though I pat myself on the back so publicly for it, has its price: a fair amount of duplicated effort. One example of this are the author-tests, or maintainer-tests if you prefer.

These are the tests that are really meant to be run only by we the authors, on our own modules. You, the user, really have nothing to gain from watching them run, because if any of them fail you really don’t have a stake in it. These are the tests for the cleanness of the POD structure, tests of the integrity of the YAML metadata file, etc. If “META.yml” doesn’t pass that test, that’s a lot less meaningful to you than if the test script for the actual functionality has one or more failures.

This is where Adam K. stepped in with Test::XT. It generates these boilerplate author/maintainer tests for you. Which handily beats my old practice of copying from an existing project when creating a new one. The test-files that it generates include checks, based on documented environment variables, that prevent the test-suites from running unless you have specified that you (as the author or maintainer) want to run them. It looks at two variables, in fact, to let you choose whether to run them during author-initiated builds, during designated “integration” (nightly, hourly, etc.) builds, or both. The logic is set up in a way that ensures the dependent modules (Test::Pod, Perl::Critic, etc.) don’t get loaded even for the purpose of the “can-we-run-these-tests” test. Which helps to avoid failing the “list of prereqs does not match actual use” metric on CPANTS. (And yes, I still have some modules that fail that, as I haven’t back-ported this to everything yet!)

It’s a simple module, not at all complex. I hope to offer some extensions or patches to it in the future, as it has been greatly helpful to me and I want to help make it even more so. So check it out– even if you aren’t a CPAN author you may find it useful for the tests you develop in your day-to-day work!

Tags: , ,

Stamp Out Tab-Stops! (An Unsung Holy War)

August 3rd, 2009 | 2 Comments | Posted in Perl, PHP

At $DAY_JOB, I have for the first time encountered a coding style that I have problems adapting to. It’s not that I can’t do it; I easily re-configured my editors and IDE settings to accomodate it. It just leaves a bad taste in my mouth every time I commit code with tab characters still present.

It’s a quiet holy war, nowhere nearly as loudly fought as Perl vs. Python (Perl, naturally) or Emacs vs. Vi/Vim (I take the Switzerland stance and use both while advocating neither). Do you expand your tabs to spaces? Do you even have tabs at all, have you instead configured your editor-of-choice to bypass them entirely? Do you prefer to retain tabs? Or do you, like the author of these styling guidelines, advocate mixing spaces and tabs together?

To me, that’s the worst of the options– even though you’re using spaces to make sure that sub-elements of a statement still line up, it only takes a few missed lines and a viewer (such as “less”, or converted-printing such as “enscript”) with tab settings that are different than yours. Then, you have source code whose flow is so much harder to read than it needs to be.

And what are the arguments for even using tabs? They’re a hold-over from the days of mechanical typewriters, and some cool steampunk hacks notwithstanding, we don’t use those anymore. Non-software-professional office workers don’t even use them anymore! The closest they come is in word-processing software such as OpenOffice.org or Microsoft Word. Neither of which, last I checked, were popular as source-code editors.

My coding style has evolved over the years, and the way I code now doesn’t always match what I wrote 15 years ago. Sometimes when I look at my older code it can be painful to see stylistic shortcomings. But when I look at code that uses tabs, let alone that mixes tabs and spaces, it’s often outright jarring. Block structures in Java, Perl, even PHP can be all over the place if the author wasn’t careful. And if there were multiple authors, it’s almost guaranteed to be that much worse.

I’ve heard people say, fairly-recently even, that a tab-stop saves bytes over using spaces for the same indentation. Why is this even remotely an argument when terabyte disks are under $200? Is the savings of a few bytes here and there worth the headache of reading code who’s format is skewed by inconsistent tab layout?

I’ve also heard that it’s a matter of keeping people to a consistent style, and that not everyone has their editors set up to convert tabs. That’s an even weaker argument, since even as I started re-learning Vi/Vim, it took me mere minutes to find the proper option to make it always use spaces in place of tabs (that would be “expandtab”, in case you were wondering). In Emacs you can also configure it (because really, what can’t you configure in Emacs?), and likewise it is trivial to set up in Eclipse, Padre, jEdit, etc., whichever editor is your favorite. And consistency in style is so much more than just tabs versus spaces, it seems like an insult to the question of stylistic guidelines to reduce them to this argument. And with tools such as pertidy, there’s no reason to be that concerned about the relationship between editing and style-adherence.

So help me in my goal of stamping out every last tab-stop in source code that you find! End the tyranny of the mechanical typewriter!

Tags: ,