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.

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.

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.

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.

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...

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.

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.