Having been a little busy for the past month and a half, my attempts to do the next Perl Template Roundup got delayed from September into October, partly by adding a number of new engine plugins to Template::Benchmark:

• HTML::Mason

• HTML::Macro

• Parse::Template

• Solution

• Text::Clevery

• Text::Templet

Support for pure-perl mode Text::Xslate was also added and two new cache-types for Template::Sandbox (Cache::FastMemoryCache and Cache::Ref::FIFO).

Then I had to sit around and wait for spare CPU time to actually run the multiple-days of benchmarks, unfortunately this clashed with me using that computer as I rushed to release stable versions of my other projects in anticipation of being too busy starting my new job.

Once the projects were out the door I could run the benchmarks, which completed mid-October, just in time for that whole "too busy" thing to kick in as I tied up loose ends before my start date.

Anyway, it's now November, and I figured I ought to do something about these reports... so here you go: the October 2010 Perl Template Roundup (belatedly).

In the next few weeks I'll be starting to gather data for the September 2010 edition of Template Roundup, and so now is your last chance for any requests or suggestions to make it into the report.

Take a look at the previous reports or the list of template engines supported by Template::Benchmark and let me know if there's a template engine you'd particularly want to see benchmarked, or some feature that isn't covered.

You can either make your suggestion in the comments thread below or contact me via the contact page.

I'm quite looking forwards to seeing how well Text::Xslate does this time around, it was far and away the fastest fully-featured template engine in a persistent environment last time, but the recent changelogs suggest some great strides have been made to make it even faster in the past month.

Been a busy couple of weeks, but just thought I'd mention in case any of my previous contributors are interested: all my published projects are now available on GitHub.

Converting from CVS to git was surprisingly painless, although complicated by the fact that each project repository had a public and private part, since I manage each project's section of my website as part of the project, and I doubt anyone else has much use for the mishmash of templates and config files I use for that.

It was pretty easy add a regexp to prune out the bits I didn't want, convert my unix login to my git user details, and shift everything up a directory with the following commands:

git cvsimport -v -d /opt/cvs -S '(bin/|site/)' \
  -C git-Text-Matrix Text-Matrix \
  -A ~/git-cvsimport-authorconv.txt
cd git-Text-Matrix
git mv src/* .
rmdir src
git commit -m 'Shifted everything up a directory so repository root matches public section of old CVS project.'

I then did the same for the private directories and then placed the newly created directories back under my old project dir as separate git repositories.

Things seem to test OK, although looks like I've been a bit inconsistent with whether I've included generated files like MANIFEST and META.yml from project to project. I expect that'll sort itself out next time I work on any given project.

I really am kicking myself for sticking to CVS so long rather than giving git a try, if anyone else is lingering: make the effort, it'll repay itself within days.

Git honestly makes it effortless to do all those "Best Practice" things you never quite do with CVS because it's too much hassle.

GitHub is just icing on the cake.

In the comments to a previous article, I mentioned that I use Module::Starter when starting a new distribution.

I actually use a custom profile along with the very handy Test::XT to produce robust release tests that won't break when people are just trying to install with the minimum fuss.

I thought it might be useful for other people if I wrote a quick tutorial on how to achieve the same results themselves.

As mentioned in my previous article, "Still Alive and What I've Been Up To", I've been working on a way to let me use Pod::Weaver without being forced down the route of using Dist::Zilla.

(The reason for not using Dist::Zilla is that its work-flow doesn't fit mine.)

To that end I've developed App::podweaver, Pod::Weaver::Role::SectionReplacer, and Pod::Weaver::PluginBundle::ReplaceBoilerplate.

All the above are GitHub because they're not yet ready for CPAN release, since they lack important things like, oh, tests that they don't go nuts and delete all your code.

That said they're at a stable enough stage that I've used them to weave their own documentation without trouble, and are potentially of enough use and interest for me to put them up for early adopters to take a look at, or for people to copy the guts to do their own thing with.

For more details on what does what, carry on reading below the cut.

I've failed the Perl Iron Man Challenge again, but I'm still alive, just busy.

I've had a couple of articles semi-written for the past two weeks, but they still very much works-in-progress, because they're about projects that are still... very much in-progress.

So I thought I'd post an interim report in the style of the "What I'm Working On" posts that crop up every so often.

One project is getting Pod::Weaver to do what I want, as mentioned in my previous article, "To Dist::Zilla, or not to Dist::Zilla?", this has involved using Moose for the first time, Pod::Weaver for the first time, Pod::Elemental for the first time, Config::MVP for the first time, and Git for the first time.

I maintain 38 Perl modules across 5 distributions on CPAN, which by the standards of some authors puts me firmly in the small fry category.

Nevertheless, the logistics behind each release does tend to drag after the 78th time. (Not that I'm counting.)

For example, bumping version numbers on each of the, 22 and rising, plugin modules for Template::Benchmark is just the sort of mindlessly repetitive thing that screams out to be automated, but I end up doing it manually each release.

Now this sounds exactly like a job for Dist::Zilla, so why haven't I switched?

Thanks to a bug report by Adam Kennedy for Template::Benchmark, I found myself needing to do some testing on Windows this week.

Now to be clear, I've always loathed using Perl on Windows. I appreciate that some people use it, and I'm of the opinion that I should write my modules to work on it, but I'm happy to never touch it myself.

So it was with no small amount of trepidation that I downloaded Strawberry Perl for Windows.

Here are my first impressions.

I've just uploaded Template::Benchmark v1.03_02, the first release candidate for v1.04.

This adds two of the features that have been on my long-term goals for this project: custom datasets, and per-feature repeats.

The first lets you supply your own data-structure to use within the benchmark templates (or choose from a presupplied list).

The second lets you choose on a feature-by-feature basis, how often that feature should be used in the generated benchmark template, rather than only choosing how often the entire template would be repeated.

Taken together, these two features allow you far greater control of the generated benchmark, allowing you to tailor it to fit your individual needs with greater precision, read on for more details.

Having gone quiet for a month, I've managed to avoid distraction enough to release a project which had been stubbornly stalled for the past couple of months: a Perl Template Roundup.

Based on Template::Benchmark it's an exhaustive (and exhausting) bunch of benchmarks for a collection of Perl template engines, sliced this way and that way by feature, caching, phase of the moon, and anything else I could measure.

Regexps are one of Perl's strongest features, but they're also one of the causes of Perl's greatest criticism: that it looks like line noise.

If you've ever had to examine someone else's regexp, or worse debug one, you'll probably agree that there's some merit in that criticism.

It doesn't have to be that way however, there's some simple steps you can take to make your regexps more readable and more maintainable, and this week we look at one of them: the /x modifier.

My skunk-works project of the past month or so has reached the stage where I need some beta-testing feedback.

So I'm looking for some Perl people interested in taking a little time to look over a project related to Template::Benchmark, to find things broken and make suggestions for improvements.

You'll need only a web browser and email client, no Perl or coding expertise is required although the content of the beta is probably only of interest to a developer.

If this sounds like you and you're interested in Perl templating engines and their performance, please read the main article below and consider joining the beta.

For almost three months now, I've been writing as part of the Ironman Perl Blogging Challenge, so it seemed like a good point to pause and take stock, to recap some of my better posts for new readers and to see what's changed since I posted them.

It's also a good spot to comment on the experience of participating in the challenge and to vote on mst's Ironman forfeit.

Well, after 13(!) point releases, I'm happy enough with Template::Benchmark to make the first stable release.

v1.00 should be hitting a CPAN mirror near you sometime soon.

Now that it's officially released, I thought I'd go into a little more detail about what Template::Benchmark does, how it can be useful to you, what motivated me to write it in the first place, and some thoughts on where to take the project next.

I had hoped to post a somewhat more exciting article this week about a project I've been working on for a while.

Unfortunately, it isn't ready for announcing yet... but I do have the following teaser:

Maybe next week I'll be done...

Continuing from my previous article "Anchoring Regexps", another common regexp mistake I see is use of * where the author really meant +.

So today I cover + and *: what's the difference and why does it matter?

Is it just me or has the ironman feed started mangling some people's posts?

For example, this is supposed to be the second paragraph, not mangled into the first. It also seems to be stripping urls from those people's posts too.

It used to work fine, I hope it's just a temporary artefact of the new ironman system, because it's horrible to have your nicely-formatted blog intro mangled into an unreadable wall of text.

Unfortunately I can't tell, there's no list of known issues or anything else about the ironman feed on the ironman site.

A common mistake I find whenever I look at someone else's regexps, is a failure to anchor the regexp.

This is often, in my experience, the single biggest thing you can do to improve the performance of a regexp: it's one of those things you should learn to do in every regexp where applicable, which should be almost every regexp unless you're specifically looking for "something somewhere in the middle but I don't know where".

So, what is anchoring, and why does it have such a big impact?

Even with twenty thousand distributions on CPAN, a figure that should truly boggle the mind, I'm still often surprised to find myself trying to do something reasonably basic that hasn't been covered already.

While writing Template::Benchmark I wanted to lay out a "feature matrix", a matrix of template engines and the features they supported: a simple grid of Y/N characters in even, regular spacing.

To my surprise none of the CPAN table modules covered this, they'd all force the layout to depend on the width of the column labels or try to force the column labels to wrap at single-character width. So I hacked together some ugly code myself and got on with writing the rest of Template::Benchmark.

As with all ugly one-off code though, you find yourself wanting to use it elsewhere and constrained by how un-resuable it is.

Well, I did what I should have done in the first place, I made it Text::Matrix - Text table layout for matrices of short regular data.

Only a beta 0.99_01 release, but should be hitting a CPAN mirror near you shortly if it isn't there already.

See below the cut for example output and more details.

As part of my development environment for Template::Sandbox, I maintain a suite of regression benchmarks, using Template::Benchmark against all previous versions of the distribution.

While a crude tool, it's something I find useful and thought I'd use this week's column to share how I automated as much pain away as I could.

I've been working on Template::Benchmark some more this week and I've hit a brick wall, one entirely of my own stubborn making.

One of the major roadblocks to releasing v1.00 is that I'm unhappy with the name of one of the major conceptual elements of the module: I want to come up with a better name and, it being a major element, I don't want to change it after I've moved to a stable release.

Naming things well is something I'm extremely fussy about and one I've thought about often, so the factors that make a good name seemed like a worthy topic for this week's blog.

Last week, in "Monkey-patching Benchmark.pm to auto-correct custom controls", we covered how to monkey-patch Benchmark.pm into giving us the results we wanted, and saw that one alternative method was to wrap the module instead.

This week, we investigate how to do this, and see what unpleasant surprises lie in wait when wrapping a procedural module.

In "Advanced Benchmark Analysis I: Yet more white-space trimming", I mentioned that you could automatically take into account the cost of your control benchmark and eliminate it from the rest of your results.

This blog entry shows you how to monkey-patch Benchmark.pm to let you do just that.

Today I released a new beta of Template::Benchmark (v0.99_07) and one of the changes, along with the addition of 4 new template engine plugins (Tenjin, Template::Tiny, Text::Template::Simple and NTS::Template), is that it splits the author/release tests away from the install tests.

This was a royal PITA, so I thought I'd cover the how and why of what was done.

In my previous blog entry, "Advanced Benchmark Analysis I: Yet more white-space trimming", I left you with the thought that our benchmarks changed with changing input.

This article shows you how to analyze those changes and how to draw conclusions from them.

Seems my previous blog, "Some simple "white-space trim" benchmarks" caught people's attention, and I've received some interesting suggestions and observations worthy of a followup article, this also gives me the chance to delve into explaining more advanced benchmark analysis.

So, deep breath, here goes.

Laufeyjarson asked on Monday, about stripping whitespace from both ends of a string. The comments contains lots of suggestions, but no hard figures, so I thought I'd reproduce them here along with the code used to generate the benchmarks - it provides a simple example of how to write a quick and reliable benchmark.